Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [CMS] Oddzielenie kodu PHP od (x)HTML
Forum PHP.pl > Forum > PHP
WebCM
Niektórzy zwracają uwagę, że kod PHP powinien być oddzielony od HTML. Tylko jak to rozumieć? Szablony dla każdego modułu?
  • artykuł, plik, obraz, nowość itp. (z tym się zgadzam)
  • prywatne wiadomości - trochę skomplikowane, bo kod HTML jest w pliku, który wyświetla listę folderów, pobiera ilość wiadomości należących do zalogowanego użytkownika i dołącza podmoduł (np. redagowanie, wyświetlanie) - to znaczy, że powinny być dołączane jeszcze 2 pliki wyglądu?
  • wstawki - np. link do profilu użytkownika bądź do innych podstron - myślę, że tego nie trzeba oddzielać
  • komentarze, nowości, lista plików, artów, użytkowników - tu trzeba albo pętlę FOREACH w szablonie z dozwolonym kodem PHP, albo odczytać szablon funkcjami file_get_contents() i str_replace(), co uniemożliwi użycie kodu PHP (chyba, że zastosuję system szablonów - najlepiej własny)
  • edycja danych użytkownika, itp. - podobnie jest też w PhpBB
  • panel administracyjny - tu chyba nie ma wielkiej potrzeby na oddzielenie kodu PHP od HTML
W związku z tym mam jeszcze kilka pytań.

A. Czy oddzielenie kodu HTML od PHP we wszystkich modułach jest bardzo istotne?
B. Czy odczyt danych powinien następować przed wysłaniem do przeglądarki znacznika <html>? Aktualnie robię to tylko dla kategorii oraz artów, plików, obrazów, stron informacyjnych, aby móc zmienić tytuł <title>.

Chciałbym poznać Waszą opinię na ten temat. Może jeszcze dokonam zmian, bo to dopiero początek tworzenia kolejnej wersji skryptu.
domis86
hmmm.
Ja bym powiedzial: "oddzielenie mechaniki od wygladu"

mechanika to jest np:
-dodanie newsa do bazy danych
-zaktualizowanie danych usera
-zalogowanie uzytkownika

mechanika to sam PHP


za to wyglad to np:
-szablony calych stron
-szablony elementow (np sama tabelka)
-szablony maili
-wynikowy xml


w wygladzie moze byc oczywiscie PHP, tylko taki "read-only" - nie moze zmieniac nic w bazie, plikach itp

wyglad moze uzywac tez jakichs funkcji "read-only" z mechaniki, jezeli mowimy o MVC to z modeli - funkcji w stylu pobierz liste userow, pobierz newsy, pobirz profil usera, etc
Ludvik
Trochę źle rozumiesz oddzielenie kodu PHP od (X)HTML... Nie chodzi o to, żeby go fizycznie oddzielić, bo w przypadku dynamicznych stron jest to zadanie karkołomne i raczej nie wiąże się z poprawą wydajności.

Pamiętaj, że PHP jest nienajgorszym narzędziem do tworzenia szablonów...

Nie chcę wyskakiwać z MVC (chociaż byłoby mile widziane, gdybyś pogłębił swoją wiedzę w tę stronę), ale oddziela się logikę (czyli operacje na danych) od prezentacji (czyli wyglądu i interfejsu). Dzięki temu:
  • oddzielamy od siebie kod odpowiedzialny za zupełnie różne zadania, co skutkuje większą przejrzystością kodu
  • likwidujemy zależności pomiędzy tymi warstwami, dzięki czemu możemy chociażby zmieniać interfejs bez wpływu na logikę aplikacji
Powinieneś najpierw pobrać/obrobić dane, a następnie przekazać je do szablonu, który je po prostu wyświetli.
domis86
Cytat(Ludvik @ 21.06.2007, 12:36:21 ) *
Powinieneś najpierw pobrać/obrobić dane, a następnie przekazać je do szablonu, który je po prostu wyświetli.

Ha! A właśnie, że nie. aaevil.gif
Jeżeli chcesz oddzielić te warstwy to właśnie sam szablon powinien pobrac (np uruchomic jakąś funkcje z modelu) dane ktore potrzebuje. Wtedy jest niezalezny.
Mozna mu przekazac jednak np jakies parametry.
Cysiaczek
@domis86 - nie zgadzam się z twoją opinią. Owszem, można tak zrobić, ale moźna też tak jak napisał Ludvik. Sam zresztą optuję za tym rozwiązaniem.
Twoje ma wiele wad, bo w konsekwencji operujesz widokami, a nie logiką (tym co chcesz zrobić). Gdy zmienisz listę parametrów dla funkcji, którą masz w 150 widokach, to w 150 będziesz musiał ją poprawić. Gdy zechcesz przekierować na inny widok, to musisz użyć najpierw funkcji buforujących.

Są po prostu dwie drogi osiągnięcia rozdzielenia warstw widoku i logiki.

Pozdrawiam.
Ludvik
domis86: Poczytaj o wzorcach Dispatcher View i Service To Worker. Pierwszy z nich, o którym Ty myślisz, jest stworzony do aplikacji o prostej logice. Drugi z nich lepiej spisuje się przy większych projektach.
domis86
Cytat(Cysiaczek @ 21.06.2007, 12:55:28 ) *
Są po prostu dwie drogi osiągnięcia rozdzielenia warstw widoku i logiki.

"jezeli cos sie da zrobic na 1 sposób to da sie to zrobic na nieskonczenie wiele sposobów" aarambo.gif


Cytat(Cysiaczek @ 21.06.2007, 12:55:28 ) *
Gdy zmienisz listę parametrów dla funkcji, którą masz w 150 widokach, to w 150 będziesz musiał ją poprawić.

czyli twierdzisz, ze to nie jest skalowalne.... A wasz sposob niby jest?
WebCM
Myślę, że niektóre pliki odpowiadające za wygląd powinny być uniwersalne - tak, aby np. dla list o podobnym wyglądzie nie trzeba było stosować oddzielnych plików - czyli index.php dołącza plik funkcjonalny (pobranie i przetworzenie danych do wstawienia), a ten z kolei definiuje, który "widok" ma być dołączony - u mnie następuje to w pliku skórki na podstawie stałej MOD. smile.gif

A co z panelem administracyjnym i innymi podstronami, o których wspomniałem w temacie?

Myślę, że podzielę "widoki" na 2 części - czyli skórki i pliki struktury. W tej pierwszej - główny layout, plik konfiguracyjny i CSS oraz obrazki, a w drugim - pozostałe.
Ludvik
Cytat
czyli twierdzisz, ze to nie jest skalowalne.... A wasz sposob niby jest?

Może zamiast zadawać takie pytania przeczytaj jeszcze raz mój poprzedni post i pogoogluj. Jakoś w J2EE te rozwiązania się sprawdzają...

Jeszcze raz Ci napiszę. Mieszanie warstwy prezentacji z warstwą logiki przetwarzania jest fe.
  • mieszasz kod odpowiadający za widok i za prezentację -> syf
  • uzależniasz widok od implementacji - nie zmienisz implementacji bez zmiany widoku
Cytat
"jezeli cos sie da zrobic na 1 sposób to da sie to zrobic na nieskonczenie wiele sposobów"

Nie rozmawiamy o implementacji, tylko o pomyśle na architekturę. Albo oddzielasz widok od modelu, albo nie... Pół na pół tego nie zrobisz. Możesz wystartować od widoku, albo od logiki.

Cytat
Myślę, że niektóre pliki odpowiadające za wygląd powinny być uniwersalne - tak, aby np. dla list o podobnym wyglądzie nie trzeba było stosować oddzielnych plików - czyli index.php dołącza plik funkcjonalny (pobranie i przetworzenie danych do wstawienia), a ten z kolei definiuje, który "widok" ma być dołączony - u mnie następuje to w pliku skórki na podstawie stałej MOD.


Utworzenie widoku złożonego (Composite View) jest dobrym sposobem na uniknięcie powtarzania kodu i stworzenie "modularnego" widoku.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.