Aby nie kopiować treści problemu, zamieszczam link do tematu w grupie dyskusyjnej.
http://groups.google.pl/group/pl.comp.lang...8e6cc795ccaa382
Co o tym myślicie? Aktualne rozwiązanie - content.php przed <html>, zaś funkcjonalny mod/art.php i "widok" views/art.php w odpowiednim miejscu w <body> - po drobnych zmianach może być dobre, lecz trzeba dołączać 3 pliki. Zresztą bez żadnych zmian byłoby podobnie (też 3 pliki).
Może jednak są lepsze sposoby na prawidłowe oddzielenie kodu PHP od HTML (z wstawkami PHP)?
Z innymi modułami nie powinno być tyle problemów - dołączenie pliku funkcjonalnego przed <html>, który ustawia stałą MOD (jej wartością jest nazwa pliku "widoku").
[PHP][CMS] Oddzielenie kodu PHP od HTML
Re: [PHP][CMS] Oddzielenie kodu PHP od HTML
W sumie warstwą wyglądu zajmuje się arkusz stylów (XSLT, czy CSS), więc układ tagów nie ma dużego znaczenia(szczególnie dla XSLT). Ja sam stosuje na stronach jeden plik layoutu ze zmiennymi pod które podstawiane są wyniki działań metod obiektu strony. Wszystkie inne tagi staram się stosować semantycznie i ustawiać identyfikatory, bądź klasy dla ważniejszych elementów, by można było bez edycji kodu PHP zmienić wygląd strony przez CSS.
Czasem pociągające jest również użycie XSLT, to jest dopiero oddzielenie wyglądu od treści
.
Czasem pociągające jest również użycie XSLT, to jest dopiero oddzielenie wyglądu od treści
.Re: [PHP][CMS] Oddzielenie kodu PHP od HTML
Wracając jeszcze do układu plików - w odpowiednim miejscu w BODY trzeba wyświetlić wynik. Są 2 sposoby:
A. Wykorzystanie buforowania wyjścia i dołączanie modułów wraz szablonami przed <html>. W ten sposób mamy już całą zawartość do wyświetlenia + ustawiony tytuł <title>. Rozwiązanie zapisuje wynik działania modułów w pamięci RAM (albo SWAP
) - wraz z komentarzami, aby potem je wrzucić do szablonu głównego w <body>.
:: Znacznie większe zużycie RAM-u (np. 10 jednoczesnych wywołań po 50 kb = 500 kb - ok 1 MB).
B. Wszystkie moduły są dołączane z głównego szablonu na podstawie stałej MOD zdefiniowanej przez index.php. Jednak przed <html> dla modułów treści (pliki, arty, wolne strony, newsy, obrazy) wykonywany jest dodatkowy plik - content.php, który pobiera dane o zawartości i jej kategorii oraz ustawia tytuł, gdy użytkownik ma dostęp. Dla innych modułów <title> jest ustawiany automatycznie przez index.php - jeżeli istnieje klucz w tablicy $lang (w pliku języka) taki sam, jak nazwa modułu (np. user, cats, poll). Zresztą tytuł strony "Pokaż użytkownika: anonim" nie jest na tyle ważny jak tytuły kategorii (nimi zajmuje się index.php) bądź artów, plików, obrazów, wolnych stron czy nowości, co znacznie ułatwi pozycjonowanie (niektórzy też pomijają wpisy w Google, jeżeli część tytułu nie jest pogrubiona).
:: Mniejsze zużycie RAM-u, lecz narzucony szablon dla większości modułów (nie liczyć np. głosowania, logowania czy pobrania pliku, bo to się wywołuje z innych plików niż index.php)
Być może zostanę przy B jak aktualnie, chyba, że są znacznie przekonujące argumenty za rozwiązaniem pre-generowania (A), wtedy piszcie, co wiecie.
A. Wykorzystanie buforowania wyjścia i dołączanie modułów wraz szablonami przed <html>. W ten sposób mamy już całą zawartość do wyświetlenia + ustawiony tytuł <title>. Rozwiązanie zapisuje wynik działania modułów w pamięci RAM (albo SWAP
) - wraz z komentarzami, aby potem je wrzucić do szablonu głównego w <body>.:: Znacznie większe zużycie RAM-u (np. 10 jednoczesnych wywołań po 50 kb = 500 kb - ok 1 MB).
B. Wszystkie moduły są dołączane z głównego szablonu na podstawie stałej MOD zdefiniowanej przez index.php. Jednak przed <html> dla modułów treści (pliki, arty, wolne strony, newsy, obrazy) wykonywany jest dodatkowy plik - content.php, który pobiera dane o zawartości i jej kategorii oraz ustawia tytuł, gdy użytkownik ma dostęp. Dla innych modułów <title> jest ustawiany automatycznie przez index.php - jeżeli istnieje klucz w tablicy $lang (w pliku języka) taki sam, jak nazwa modułu (np. user, cats, poll). Zresztą tytuł strony "Pokaż użytkownika: anonim" nie jest na tyle ważny jak tytuły kategorii (nimi zajmuje się index.php) bądź artów, plików, obrazów, wolnych stron czy nowości, co znacznie ułatwi pozycjonowanie (niektórzy też pomijają wpisy w Google, jeżeli część tytułu nie jest pogrubiona).
:: Mniejsze zużycie RAM-u, lecz narzucony szablon dla większości modułów (nie liczyć np. głosowania, logowania czy pobrania pliku, bo to się wywołuje z innych plików niż index.php)
Być może zostanę przy B jak aktualnie, chyba, że są znacznie przekonujące argumenty za rozwiązaniem pre-generowania (A), wtedy piszcie, co wiecie.
Re: [PHP][CMS] Oddzielenie kodu PHP od HTML
(7.01.2008) - Wypełnij ankietę - to tylko chwila
ankieta na temat budowy szybkiego CMS-a
Doszedłem do wniosku, że system szablonów jest potrzebny, jeżeli chcę (prawie) całkowicie oddzielić wygląd (HTML, CSS) od logiki (PHP, SQL), ale działający na innej zasadzie niż obecne.
Kompilowane szablony do kodu PHP nie są najlepszym wyjściem. Rozwiązanie podobne do zaproponowanego wcześniej kompromisu, czyli:
- instalacji skórek w PA
- rekompilowania ich na żądanie
- tradycyjnego dołączania skompilowanego kodu przez include() bez żadnych klas szablonów (jak dotąd). Zadowolony jest zarówno ten, który zna tylko HTML i CSS, a także ten, który chce wprowadzić kod PHP w pliku stylu).
Na czym polega problem? Przede wszystkim na wyświetlaniu elementów powtarzających się. Są 2 wyjścia:
1. W logice przygotowujemy dane specjalnie dla skórki. Styl dołączamy na samym końcu. Wtedy dopiero przesyłane są dane do przeglądarki. W skórce zaś używamy pętli, np. foreach. Trochę większe zużycie RAM-u na większych stronach.
2. W logice przy każdej iteracji wywołujemy funkcję zdefiniowaną w pliku skórki. Dane wysyłane są po przetworzeniu jednego elementu. Niestety, w niektórych przypadkach trzeba deklarować zmienne globalne.
3. Chyba nie będziemy dołączać 2 lub 3 plików, w czym 1 jest pojedynczym elementem wyświetlanym w pętli?
Jakiego systemu szablonów potrzebuję?
Przede wszystkim - szybkiego i lekkiego. Można użyć np. funkcji DOM, choć może są lepsze wyjścia. Cechy:
1. Wyjmowanie fragmentów - to ma wiele zalet, m. in.
a) brak w.w. problemów z wyświetlaniem elementów pętli
b) użycie tego samego kawałka kodu w różnych miejscach
2. Szybka podmiana wartości.
{var} -> $var, itd.
3. Inne instrukcje - np. IF (nieraz przydaje się).
Alternatywne rozwiązanie, coraz bardziej popularne
Postawienie na CSS. W skrócie:
- niektóre moduły mają własne style CSS
- niewielka ilość kodu HTML wplątana w PHP w części modułów
- wiele elementów ma swoje klasy lub ID
- prawie cały wygląd można zmienić w arkuszach CSS
- pliki stylów wciąż istnieją dla modułów \"nieskomplikowanych\" (czyli bez wyświetlania elementów wymagających dostosowania wyglądu w pętli).
Może znacie jeszcze inne, lepsze rozwiązania? W każdym razie na coś trzeba postawić.
ankieta na temat budowy szybkiego CMS-a
Doszedłem do wniosku, że system szablonów jest potrzebny, jeżeli chcę (prawie) całkowicie oddzielić wygląd (HTML, CSS) od logiki (PHP, SQL), ale działający na innej zasadzie niż obecne.
Kompilowane szablony do kodu PHP nie są najlepszym wyjściem. Rozwiązanie podobne do zaproponowanego wcześniej kompromisu, czyli:
- instalacji skórek w PA
- rekompilowania ich na żądanie
- tradycyjnego dołączania skompilowanego kodu przez include() bez żadnych klas szablonów (jak dotąd). Zadowolony jest zarówno ten, który zna tylko HTML i CSS, a także ten, który chce wprowadzić kod PHP w pliku stylu).
Na czym polega problem? Przede wszystkim na wyświetlaniu elementów powtarzających się. Są 2 wyjścia:
1. W logice przygotowujemy dane specjalnie dla skórki. Styl dołączamy na samym końcu. Wtedy dopiero przesyłane są dane do przeglądarki. W skórce zaś używamy pętli, np. foreach. Trochę większe zużycie RAM-u na większych stronach.
2. W logice przy każdej iteracji wywołujemy funkcję zdefiniowaną w pliku skórki. Dane wysyłane są po przetworzeniu jednego elementu. Niestety, w niektórych przypadkach trzeba deklarować zmienne globalne.
3. Chyba nie będziemy dołączać 2 lub 3 plików, w czym 1 jest pojedynczym elementem wyświetlanym w pętli?
Jakiego systemu szablonów potrzebuję?
Przede wszystkim - szybkiego i lekkiego. Można użyć np. funkcji DOM, choć może są lepsze wyjścia. Cechy:
1. Wyjmowanie fragmentów - to ma wiele zalet, m. in.
a) brak w.w. problemów z wyświetlaniem elementów pętli
b) użycie tego samego kawałka kodu w różnych miejscach
2. Szybka podmiana wartości.
{var} -> $var, itd.
3. Inne instrukcje - np. IF (nieraz przydaje się).
Alternatywne rozwiązanie, coraz bardziej popularne
Postawienie na CSS. W skrócie:
- niektóre moduły mają własne style CSS
- niewielka ilość kodu HTML wplątana w PHP w części modułów
- wiele elementów ma swoje klasy lub ID
- prawie cały wygląd można zmienić w arkuszach CSS
- pliki stylów wciąż istnieją dla modułów \"nieskomplikowanych\" (czyli bez wyświetlania elementów wymagających dostosowania wyglądu w pętli).
Może znacie jeszcze inne, lepsze rozwiązania? W każdym razie na coś trzeba postawić.