XSLT po stronie klienta = pomyłka
Najczęściej nic się nie zyskuje przez wysyłanie źródłowych danych i arkuszy do ich przetworzenia, skoro można wysłać od razu przetworzone.
Rzadko kiedy arkusz XSTL będzie zajmował mniej, niż kod XHTML, który wygeneruje. Wszelki zysk, który taka kombinacja może dać jest marginalny w porównaniu ze standardową kompresją HTTP (transfer-encoding:gzip).
Strony w XSLT i dłużej się ładują, ponieważ nie mogą być wyświetlane progresywnie (XSTL nie może działać poprawnie póki nie są załadowane wszystkie dane i cały szablon).
No i tak samo jak każda technologia “na krawędzi”, XSLT powoduje problemy z kompatybilnością. Nie jest wspierany przez roboty (papa, Google). Jeszcze nie wymarły przeglądarki, które sobie z nim nie radzą.
Może jednak?
Wyjątkiem mogą być AJAXowe aplikacje/widgety, które potrzebują wyciągnąc i przetworzyć dane z XML, którego serwer nie ma możliwości przetworzyć. Da się wtedy obejść z samym DOM, ale da to dużo dłuższy i bardziej zamotany kod niż użycie XPath/XSLT.
XSLT jako system szablonów (po stronie serwera) = dobry
Po stronie serwera XSLT jest już o niebo lepszy i z przyjemnością go używam.
Zalety
- Bardzo szybki (chyba, że strasznie coś zamotasz). Cała ciężka robota jest wykonywana przez skompilowany kod silnika XSLT, a nie przez interpretowany kod PHP, ktory jeszcze interpretuje kod języka szablonów.
- Nie da się zrobić nieprawidłowego XML. Dzięki temu można słać prawdziwy xhtml bez obaw, że jakaś byle encja sypnie całą stronę.
- Odpada większość bolączek związanych z HTML injection i atakami XSS — nie ma wątpliwości co jest tekstem, a co kodem. Ewentualnie można obcy \XHTML skuteczne przefiltrować.
- Jeśli się umie dobrze dobrać i napisać template'y, to kod formatuje się “sam”, podobnie jak w CSS — wystarczy podać odpowiednie dane, a szablony je znajdą, przefiltrują, przeformatują i złączą w sensowną całość.
Wady
- Wymaga podania danych w postaci drzewa DOM. Interfejs DOM ma upierdliwie długie nazwy metod i wymaga kilku wywołań nawet do podstawowych rzeczy jak dostawienie byle napisu. Można sobie z tym radzić pisząc własne metody skracające najczęstsze operacje (dodaj\element\razem\z\tekstem()) albo konwertery tablic PHP na DOM (wtedy podawanie danych do XSLT może przypominać obsługę Smarty).
- Jeśli za punkt honoru przyjmie się nieużywanie niestandardowych rozszerzeń XSLT, to szablon nie może zażądać podania określonych danych — aplikacja musi z góry wiedzieć czego szablon potrzebuje i podać mu te dane. Czasem przez to marnuje się czas na wczytanie rzeczy, których szablon nie użyje.
- Tak jak z CSS — trudno jest na początku zrozumieć filozofię działania. Podobnie jak CSS wyciąga <font> z kodu i ukrywa formatownaie w selektorach, XSLT rozbija tagzupę i pętle na osobne szablony.
- Składnia XSLT przez oparcie o XML jest strasznie rozlazła. Bez edytora z inteligentnymi makrami (jak “snippets” w TextMate) klepanie wszystkiego jest uciążliwe.
XLST w PHP5 bardzo łatwo się pobawić — zobacz php.net/dom i php.net/xsl
