Architektura baza->php->xml->xslt->html Opcje

[rmn]

Co myslicie o takim pomysle w porownaniu do wyrzucania outputu od razu w html albo w smarty (lub innego systemu templetow)?

Ten post edytował rmn 27.11.2005, 13:25:12

[chmolu]

Jest to rozwiązanie ciekawe i bardzo wygodne jeśli chodzi o współpracę programistów z grafikami. Projektant dostaje plik XML i może z nim zrobić, co mu się podoba za pomocą XSLT. Programista też nie zajmuje się prezentacją - jego zadaniem jest wygenerowanie odpowiedniego pliku XML z danymi.

Pomimo zalet tego rozwiązania nie zdecydowałbym się na użycie go w php. Za duży narzut czasowy i zbytnie obciążenie dla serwera. Wprowadzamy 2 dodatkowe warstwy processingu danych, a to musi wiązać się z opóźnieniami. Poza tym, osobiście uważam, że jest to zbytnie kombinowanie (overdesign).

[Ociu]

Xml-Cache ? Jak Wyżej. Ma swoje zalety, ale czas jest nieubłagany.
pozdrawiam

[dtb]

1. uzywanie smarty lub omt jest wygodniejsze (wg. mnie) od xslt
2. xsl nie jest obsugiwany przez opere (wiem bo uzywam). nie wiem jak z xslt (nie jest to to samo?)

[aleksander]

@dtb: ale transformacje xslt mozna wykonac w php:P

[matid]

IMO pomysł dobry, zresztą już jakiś czas temu sugerowałem podobne rozwiązanie. Łącząc to z systemem cache jest wystarczająco szybkie.
Co do wygody - IMO lepiej używać czegoś, co jest bardzo dobrze opisane i jest prawdziwym standardem a nie iść w stronę czegoś, co zapewne nigdy nim nie będzie (Smarty, OPT, itd.)

[ActivePlayer]

i jaki ja widze wniosek? sztuka dla sztuki...

[rmn]

Czyli wszyscy mowia ze jest fajne ale nikt nie uzywa;)

Samo generowanie xml nie jest zbyt pracochlonne (szczegolnie w php5) prblem pojawia sie jednak przy xslt, ktore jest moim zdaniem bardzo niewygodne i trudne do debuggowania..

Jesli chodzi o szybkosc to wcale nie jestem taki przekonany. Czy ktos robil moze jakies testy, bo moim zdaniem dane sa przetwarzane tyle samo razy co przy np. smarty.

Duzym plusem jest to, ze osoba zajmujaca sie html nie musi uczyc sie smarty, ktorego zastosowania ograniczaja sie tylko do php.

Najwiekszy plus jak dla mnie to sam fakt, ze nasza aplikacja wyrzuca dane w xml-u, ktory mozna potem wykorzystac na wiele sposobow (mozna w zasadzie od razu generowac rozne formaty dokumentow).

[krzysztof f.]

Podejście do rozwiązania warstwy prezentacji, w oparciu o dane generowane w postaci plików xml, a następnie przetwarzane w wybraną formę prezentacji, jest rzeczywiście bardzo dobrym pomysłem. Nie jest też to nic nowego, a już na pewno nie można powiedzieć, że nikt tego nie robi. Na takim podejściu bazuje, między innymi jeden z większych i popularniejszych frameworków napisanych w javie http://cocoon.apache.org/. Powstało też kilka portów Cocoon’a napisanych w języku php. Możnaby wspomnieć chociażby: http://www.popoon.org/.

Moim zdaniem, wyodrębnienie w procesie generowania prezentacji dla naszej aplikacji, etapu przygotowania danych w formie dobrze opisanej struktury xml, daje naprawde duże możliwości tworzenia alternatywnych widoków. Zmieniając tylko proces transformacji pliku xml możemy ten sam zestaw danych przedstawić w formie stron xhtml, stron wap, pliku pdf czy doc, stworzyć rss czy też formę tekstową do wydruku.
Nie wydaje mi się żeby dobrze zaprojektowana biblioteka ustępowała wydajnościowo znanym systemom szablonów. W końcu, większość tego typu bibliotek, również musi parsować szablony podmieniając odpowiednie znaczniki danymi.

Rozważanie implementacji takiego mechanizmu tylko dlatego aby ułatwić współpracę między grafikami a programistami, wydaje mi się jednak, przerostem formy nad treścią. Osobiście nie znam żadnego grafika, który poradziłby sobie z transformacją xml i przygotowaniem poprawnych styli xsl. To zadanie spoczywałoby ciągle na programiście, ale prawdopodobnie nie byłby to już (i tak wyeksploatowany do granic możliwości ;) biedny deweloper php.

Skuteczne rozdzielenie kompetencji między programistów a grafików i projektantów xhtml zapewniają szablony. Jeśli problemem jest dla grafika, programisty xhtml, tworzenie strony pełnej dziwnych znaczników i nieznanej składni (tak jak w przypadku Smarty), można rozważyć użycie innych systemów szablonów. Chociażby opartych o tworzenie poprawnych dokumentów xml, z operacjami na szablonie opisywanymi w formie specjalnych atrybutów, dobrze wszystkim znanych tagów html (http://phptal.motion-twin.com/). Istnieją też szablony opartych o komponenty (podobne do tych znanych programistom .NET), a należą do nich systemy szablonów z popularnych frameworków wact http://www.phpwact.org/wact/template_component_architecture i PRADO http://www.xisc.com/wiki/index.php/The_PRA...a_template_file

Na koniec jeszcze, wracając do pomysłu dwustopniowego generowania widoku aplikacji, należy pamiętać, że Martin Fowler http://martinfowler.com/ opisał wzorzec projektowy, który odnosi się do tej konkretnej sytuacji Two Step View http://martinfowler.com/eaaCatalog/twoStepView.html. Zgodnie ze wzorcem należy w pierwszej fazie pobrać z obiektów dziedziny potrzebne dane i przedstawić je w sformalizowanej formie, bez żadnej informacji o sposobie prezentacji. W Twoim przypadku jest to baza->php->xml. Następnie w drugim kroku tak przygotowaną informacje prezentujemy w wybranym formacie, czyli xml->xslt->html.