To teraz moje 5gr.
Co do dużych projektów to też nie zgodzę się w całości. Dzięki wykorzystaniu xslt można zbudować komponenty webowe do wielokrotnego wykorzystania, właśnie w dużych projektach (w małych nie ma po co się tak bawić). Wiele elementów jak np. browsery pojawiają się wszędzie i realizacja przy pomocy xslt (z drugą częścią po stronie serwera) to jest bardzo wygodna rzecz.
Oczywiście xslt można też po stronie serwera zrobić, co w dużych projektach, stojących na silnych maszynach, wcale nie jest odczuwalne po stronie klienta.
Więc użycie xslt jest na pewno zaletą, którą można wykorzystać w wielu przypadkach. Zostaje tylko kwestia gdzie to przetwarzać...
I tutaj jest chyba największy problem. Oczywistym jest, że przetwarzając po stronie klienta zwiększamy wrażenie interakcyjności. Po pojedynczym, ew. trochę dłuższym, załadowaniu plików xslt następne odsłony są szybie proporcjonalnie do szybkości komputera, a nie łącza. (jeżeli wpleść w to ajax...)
Kolejna rzecz, bardziej już przemawiająca do samych twórców, to ten nieszczęsny rozdział treści, struktury i prezentacji. Pomijając całą tą ideologiczną bajkę, to pozostawiając prezentację w rękach CSS, strukturę w XSLT oraz treść w XML, mamy bardzo wygodny rozdział pracy pomiędzy członków zespołu lub chociaż zarządzanie czymś większym. Wystarczy, że jedna osoba np. odpowiedzialna za generowanie treści (np. programista PHP) będzie miał wspólny protokół z projektantem strony, to ma już w głębokim poważaniu, czy na stronie A ma wyświetlić dane w postaci tabelki posortowanej czy nie, z takimi czy innymi polami itp. itd. (W skrajnym przypadku daltonistów jak ja można rozdzielić w ogóle: XML, XSLT - nawet dla daltonisty, CSS - osoba, która zna się na kolorkach ;) ).
Co do przeglądarek, to też nie jest wcale tak źle. Przeglądarki dostaną treść strony. Czyli dokładnie to o co im chodzi. Może bez pewnej, czasem ważnej otoczki, ale jednak. Z podróżowaniem po stronce taki google też nie będzie miał problemu, o ile programista przygotuje mu instrukcję obsługi (google sitemaps). Tracimy oczywiście znaczenie. Rozpoznawanie tytułów, nagłówków itp.
Z obsługą XSLT też nie jest tak źle. Śledziłem dyskusje na forum opery. To, że w operze wprowadzają XSLT (z czego się ogromnie cieszę), to w ogromnej mierze zasługa użytkowniów. Ich presja to spowodowała (i prawidłowa postawa Opera Software).
Więc tworzyć należy z wykorzystaniem XSLT. Jeżeli się robi stronę "dla siebie", to można sobie nie zawracać głowy użytkownikami przeglądarek nie obsługujących tego standardu. Jeżeli się tworzy stronę na poważnie, to już nie ma przeproś. Liczy się pieniądz, a pieniądz to w przypadku stron ludzie, którzy ją odwiedzają. Dla wygodny robisz w XSLT, ale rozpoznajesz, czy to jest przeglądarka z obsługą XSLT, czy nie. Zależnie od tego albo wysyłasz mu XML i skrypty XSLT, a użytkownik nie może nacieszyć się cudowną technologią jaką zastosowałeś ( :D ), albo przetwarzasz to po stronie serwera i użytkownik cieszy się cieszy się tym, co ta technologia dla niego zrobiła ( o której pewnie nigdy się nie dowie... oby ).
