ďťż
Podstrony
|
telcocafeCzy wyszukiwarki lepiej sobie radzą ze stronami, gdzie każdy moduł posiada inną nazwę pliku (np. art.php, news.php), czy z tymi, w których nazwa modułu przekazywana jest w parametrze (np. index.php?co=art)? Czy to wpływa również na pozycję lub ocenę?Czy zgodność z nowszymi standardami (np. xHTML + CSS) może podwyższyć ranking? ani z takimi, ani z takimi - Google bardzo pobłażliwie indeksuje takie strony. najlepiej zainteresować się mod_rewrite lub innymi zabawami z upraszczaniem linków. zasada jest taka że żeby dobrze sie indeksowało nie powinno być w adresie "?". 2. z tego co wiem, to nie. Użytkownik bikstopa edytował ten post 09 kwiecień 2007, 18:54 ani z takimi, ani z takimi - Google bardzo pobłażliwie indeksuje takie strony. Dla google to żaden problem - indeksy dla forum. Dla inny może to trochę bardziej problematyczne. W każdym bądź razie przepisane linki ładniej wyglądają :) Czy to będzie HTML 4.01 czy XHTML 1.1 wpływu to jakiegoś nie będzie miało pod warunkiem że kod będzie czysty i zastosujesz dobry układ strony tak by "promował" najważniejsze elementy serwisu. @bikstopa bezedura przecież wiadomo że strona, która ma powyżęj X podstron jest robiona dynamicznie więc pozbycie się ? nic nie da co do zgodności to da tyle, że jak wywalisz tabelki i wygląd z kodu to będziesz miał lepszy stosunek kodu do treści a to wypada na plus O wpływie stosunku kodu do treści już gdzieś czytałem (może na tym forum). Co zaś z budową strony? Nie chodzi mi o adresy typu art.php/15, file.php/18. Przykłady: - A: art.php?id=5, file.php?id=7, category.php?id=8 - B: index.php?co=art&id=5, index.php?co=file&id=7 Sposób A na pewno jest czytelniejszy, a linki mniejsze. Myślę nad zmianą tego w F3Site wraz z wersją 3. Są jednak osoby, które wolą układ B. Czy to ma również wpływ na pozycję w wyszukiwarkach? ale kombinujesz. najprostsze sposoby są najlepsze - użyj jednego pliku - index.php do obsługi wszystkich modułów. na stronach google jest wyraźnie napisanie żeby nie używać parametrów np. ?id= bo mogą w ogóle nie być zindeksowane... Użytkownik tiger_1988 edytował ten post 10 kwiecień 2007, 12:23 Niektórzy polecają MVC, lecz nie nadaje się on dla każdego projektu, więc go (w pełni) nie wykorzystam. Trzeba rozwiązać sposób wyświetlania szablonów. Nie wiem, co wybrać. Wziąłem się za zmianę budowy skryptu, lecz tu też są schody. Mam nadzieję, że mi doradzicie szybkie, wydajne i optymalne rozwiązanie. Aktualnie stosuję: Index.php - dołącz kernel.php (podstawowe pliki) - dołącz plik modułu - mod/(moduł).php ---- zazwyczaj: pobierz dane z bazy, zdefiniuj stałe TITLE i FILE - pisz "<html>...<title>(stała TITLE)</head><body>" - dołącz plik szablonu (wnętrze <body>) ---- dołącz plik stałej FILE (zdefiniowanej przez plik modułu) - pisz </body></html> Rozwiązanie już pozwala na zmianę tytułu, używanie nagłówków i dodanie treści do <head>, lecz jest o tyle niewygodne, że trzeba używać 2 plików dla modułu - chyba, że o to chodzi. :) Np. aby wyświetlić listę użytkowników, trzeba najpierw dołączyć plik, który pobierze dane, a potem inny, który wyświetli listę - czyli plików będzie zdecydowanie więcej, chyba że część się złączy. Co jednak myślicie o startowaniu z art.php, file.php, users.php zamiast z index.php? Wtedy bardziej pasowałby tu prosty system szablonów (np. ze zmienną {content}, od której rozwaliłoby się szablon funkcją explode() na 2 części) lub dołączanie 2 plików - np. header.php i footer.php. Ewentualnie jeszcze można w pliku modułu definiować funkcję BODY() i wywoływać ją w pliku skórki - już o 1 mniej, ale za to większe zużycie pamięci w przypadku większych modułów i konieczność definiowania globalnych zmiennych, np. CFG, LANG... Tak właściwie jądro (wybór użytkownika, języka, itp.) jest w pliku kernel.php, więc nadaje się i jedno i drugie rozwiązanie. Tylko pytanie - które jest bardziej praktyczne? Wcześniej było tak:Index.php - dołącz kernel.php - pisz "<html><head>..." - jeśli plugins/(co)/head.php istnieje, dołącz go - pisz "</head><body>" - dołącz plik szablonu --- dołącz d.php ------ dołącz plik modułu lub odpowiedzialny za wyświetlenie kategorii - pisz "</body></html>"Kilka plików (np. admin, login) jest niezależnych od index.php. Rozwiązanie jest o tyle dobre, że nie wymaga umieszczania dodatkowego kodu, wyświetlającego szablon lub definiującego zmienną FILE - wystarczył sam parametr CO w adresie, by skrypt dołączył odpowiedni moduł. Może lepiej do niego powrócić? Uniemożliwia on jednak dostęp do nagłówków i zmianę tytułu z poziomu index.php (w razie potrzeby można używać innych - np. posting.php - podobnie jak istniejące już login.php czy adm.php). Myślę już nad tym cały dzień. :o Użytkownik Ferrari edytował ten post 05 maj 2007, 15:17 Niektórzy polecają MVC, lecz nie nadaje się on dla każdego projektu, więc go (w pełni) nie wykorzystam. Do większości się nadaje, w szczególności projektów składających się z "komponentów" jak CMSy. U mnie na stronach działa aplikacja z 9 aplikacjami i wszystko oparte jest o wzorzec MVC. Dodatkowa zaleta jest taka że każdą z tych aplikacji ludzie mogą wykorzystać w swoich projektach Django. Trzeba rozwiązać sposób wyświetlania szablonów. Nie wiem, co wybrać. Dziedziczenie szablonów. Masz główny szablon powiedzmy "base.html" zawierający cały szkielet strony i w odpowiednich miejscach zdefiniowane bloki. Szablon powiedzmy newsów wypełnia jeden z bloków treścią - listą newsów :) Wziąłem się za zmianę budowy skryptu, lecz tu też są schody. Mam nadzieję, że mi doradzicie szybkie, wydajne i optymalne rozwiązanie. Aktualnie stosuję: Index.php - dołącz kernel.php (podstawowe pliki) - dołącz plik modułu - mod/(moduł).php ---- zazwyczaj: pobierz dane z bazy, zdefiniuj stałe TITLE i FILE - pisz "<html>...<title>(stała TITLE)</head><body>" - dołącz plik szablonu (wnętrze <body>) ---- dołącz plik stałej FILE (zdefiniowanej przez plik modułu) - pisz </body></html> Rozbijanie głównego szablonu na kilka plików utrudnia późniejszą edycję, np. zastosowanie zupełnie innego, własnego szablonu HTML. Rozwiązanie już pozwala na zmianę tytułu, używanie nagłówków i dodanie treści do <head> Dziedziczenie u mnie robi to samo. Nawet dodaje pliki JS Greyboxa do HEAD tam gdzie są potrzebne ;) Myślę już nad tym cały dzień. :o Im bardziej się kombinuje tym wychodzą bardziej złożone koncepcje - skomplikowane, nie-elastyczne i zawodne [już to kiedyś przerabiałem] ;) Stworzenie prostego CMSa jak twój w CodeIgniter czy tym bardziej Django to kwestia godzin - dlaczego ? bo nie trzeba myśleć jak zrobić system szablonów, jak powiązać wszystko ze sobą. Frameworki a także wzorce typu MVC są od tego by programowanie zajmowało jak najmniej czasu, kod był maksymalnie prosty i skuteczny ;) I także "argument" mniejszej wydajności frameworków nad kodem od zera nie ma tu sensu. Nie licząc czasu pisania od zera zaleta wykonania strony w 0.51 sekundy a nie 0.53 jest żadna. Jak ktoś będzie miał stronę pod dużym obciążeniem to różnica wydajności tego typu nic mu nie da. Jak klientowi serwis w Django nagle stanie się młodym Onetem to jedną linijką w konfiguracji włączam RAMowe keszowanie Memcached i wydajność rośnie znacząco ;) co stosowane jest na Slashdot czy Wikipediach. Użytkownik Riklaunim edytował ten post 05 maj 2007, 16:13 MVC jest jedynie jednym z wzorców, przeznaczonym dla skryptów opartych głównie na klasach. F3Site jest pisany strukturalnie. :) Nie jest prawdą, że w tym przypadku tworzenie dodatków lub praca grupowa są niemożliwe lub trudne. To zależy głównie od struktury i przejrzystości kodu. Dobrym przykładem oddzielenia wyglądu od struktury jest system szablonów PhpBB (nie chodzi tu o widok i model). Pomimo swej obszerności strony nie składają się długo. PunBB również coś podobnego stosuje - tyle że kod jest lekki (duży +). Ewentualną zmianę budowy zostawiłem na później. Jeśli potrzebny jest dostęp do nagłówków, aktualnie można skorzystać z request.php, przeznaczonego m. in. do AJAX-a. Jest pewne, że pojęcie "wtyczki" musi istnieć ze względu na potrzebę ich instalacji i usunięcia. Są 2 metody z kilkoma możliwościami. Zaczynając od index.php: - skórki ładują dodatkowy plik, który wyświetli kod - LUB: skórki wywołują funkcję, zdefiniowaną wcześniej - LUB ostatecznie: skórki zawierają {content}, {date}, itp., ew. treść modułu jest buforowana na dysku jak w PunBB Zaczynając od art.php, file.php, itp. - skórki zawierają {content}, {date}, itp. - gorzej z wtyczkami, które albo muszą dołożyć swój plik do głównego katalogu, albo być dołączane z index.php Nie będę się więcej rozpisywał. Jeśli sytuacja będzie tego wymagać, którąś metodę zastosuję. - - - - Aktualizacja - - - - Skrypt przeznaczony jest głównie dla wolniejszych serwerów. Stawiam an szybkość. Co tu mam więcej do wyboru niż: Pozostać tak, jak jest Bazowy: index.php (skórka dołącza plik, który dopiero wybiera moduł) Niezależne od index.php są: login, request (AJAX i inny kod bez szablonu), admin. Zaletą jest, że moduły i wtyczki nie muszą się martwić o wyświetlenie szablonu. Zmiana tytułu niemożliwa. Buforowanie treści Albo podobne kombinacje. Zwiększy się zużycie RAM-u (znacznie przy dużym artykule + kod HTML z wieloma komentarzami). Bazowy plik: index.php (oprócz admina, logowania...) Zmiana tytułu i dodanie kodu do HEAD możliwe. Rozdrobnienie się na 2 pliki Czyli - 1 dołączany przed <html>, a drugi - przez skórkę. Na początku można pomyśleć - dla różnych baz inne zapytania - ale nie... Będzie dużo powtarzania kodu (bo tam nieraz byłaby większość mechanizmu modułu). Rozwiązanie powinno się najmniej różnić szybkością od pierwotnego, lecz jest też wada - rozdrobnienie nawet przy mniejszych modułach. Buforowanie początku Od <html> aż do momentu, gdzie ma się wyświetlić treść modułu. Buforowane byłoby lewe menu (lub 2, jak ktoś sobie zażyczy mieć je po lewej stronie). Wtedy tytuł można zmienić. Początek funkcją Powiedzmy - funkcja setTitle() ustawia tytuł i wyświetla górę szablonu (z lewym menu lub dwoma - podobnie jak wyżej). Treść nie jest już buforowana. Rozpoczynanie od pliku modułu Czyli od art.php, file.php, itp. - to byłyby pliki bazowe w głównym katalogu (jak w PHP-Fusion, jPortal, PunBB). Wywołują one najpierw górną część szablonu, a potem dolną. W teorii można wymyślić różne metody, a w praktyce może być inaczej. Którą z powyższych (lub inną) uważacie za najlepszą? Ważne, by skrypt był szybki, zużywał mało RAM-u i CPU (I/O również zminimalizowane), a twórcy wtyczek nie pogubili się. - - - - Kolejna aktualizacja - - - - Nie każda strona wymaga zmiany tytułu dla lepszych wyników. Rozwiązałem ten problem w ten sposób. require('kernel.php'); Header('Cache-Control: public'); $title=''; $head=''; #Akcja if($_GET['co']) { if(file_exists('mod/'.$_GET['co'].'.php')) { define('MOD','mod/'.$_GET['co'].'.php'); } else { if(file_exists('plugins/'.$_GET['co'].'/co.php')) { @include('plugins/'.$_GET['co'].'/head.php'); if(MOD!='MOD') define('MOD','plugins/'.$_GET['co'].'/co.php'); } else { define('MOD','mod/404.php'); } } } #Kategoria/strona else { if($_GET['d'] || $cfg['dfct']!=2) { if($_GET['d']) { $d=$_GET['d']; } else { $d=(int)$cfg['dfc'][$nlang]; } db_read('*','cats','dinfo','oa',' WHERE access!=3 AND ID='.$d); if($dinfo['ID']) { $title=&$dinfo['name']; define('MOD','mod/cat.pp'); } else { define('MOD','mod/404.php'); } } else { $_GET['id']=(int)$cfg['dfc'][$nlang]; define('MOD','mod/page.php'); } } ?> (... kod HTML ...) Więc: Index.php - dołącz jądro - gdy istnieje zmienna CO w adresie: --- gdy istnieje moduł wbudowany (katalog MOD), ustal jej plik --- inaczej: spróbuj otworzyć head.php wtyczki i ustal plik co.php --- inaczej: ustal plik 404 - inaczej (kategoria lub strona inf.) --- dla kategorii: pobierz dane i ustal tytuł --- ustal plik Na razie nad innym rozwiązaniem się nie zastanawiam - może w przyszłości. Użytkownik Ferrari edytował ten post 08 maj 2007, 15:14 |
|||
Sitedesign by AltusUmbrae. |