Nechoďte s XSLT na vrabce!

Před časem vzbudil článek s názvem XSLT: Jazyk budoucnosti velmi živou diskusi, která se motala kolem technických záležitostí a opomíjela podstatu problému nasazení XSLT u webových aplikací. Ta leží zcela jinde než v tom, která XSLT knihovna je rychlejší. Pojďme se dnes na otázku „XSLT na webu“ podívat SUBJEKTIVNĚ…

Dnes přinášíme další článek z rubriky Subjektivně. Jejím cílem je poskytovat našim redaktorům i českým odborníkům prostor pro jejich názory a pohledy na aktuální dění v oblasti webových technologií i na jeho vývoj do budoucna. Jedná se o osobní názory, které se nemusí vždy shodovat s názory redakce. Pokud máte co říct k aktuálnímu dění, pojďte psát Subjektivně.

Na přelomu tisíciletí se zdálo, že XML je to nejlepší, co potkalo informační technologie od von Neumanna. Stačilo otevřít libovolný odborný magazín, a čtenář nabyl dojmu, že XML je jen krok od všeobecného prosazení. O pár let později se zdálo, že bitva byla dobojována a že XML naprosto zvítězilo – byla přijata norma XHTML, rozšířily se nové formáty na XML založené, odborníci jednoznačně předpovídali, že XML vbrzku převálcuje a vytlačí veškeré ostatní formáty… V posledních několika letech se ale ukazuje, že nekritické nadšení nebylo na místě.

Nekritické nadšení totiž není nikdy na místě. Každá nová technologie projde zákonitě několika fázemi: Od hračky technologických nadšenců přes nekritické nadšení, po kterém následuje vystřízlivění, a nakonec zvítězí racionální přístup. Známá „hype cycle – křivka humbuku“ tyto fáze nazývá Techno­logická spoušť, Vrchol přehnaných očekávání, Úžlabina deziluze, Svah osvícení a Planina produktivity. Vztah webových vývojářů ke XML se právě nachází na cestě do Úžlabiny deziluze.

Hype cycle
Zdroj: Wikipedia

„Úpadek“ XML na webu

Před deseti lety se zdálo, že web bude sloužit především jako informační médium, které bude zprostředkovávat různé pohledy na velké databáze (v XML, samosebou). Jako logické se proto jevilo nasazení technologií typu XSLT nebo XPath, které dokáží v těchto souborech dat hledat potřebné informace a transformovat je na dohodnutý formát – tedy například HTML nebo PDF. Logickým pokračováním se jevilo XHTML a téměř jednoznačně přijímaná představa o „webu blízké budoucnosti“ byla založena na XML, XSLT a XHTML.

Jenže vývoj webu šel trochu jinudy. XHTML začalo stagnovat, naopak navrch získalo HTML (někdy se tento „souboj značkovacích jazyků“ označuje jako střet zastánců akademického stylu rozvoje shora se zastánci praktického přístupu a rozvoje zdola). XML nevytlačilo ostatní formáty; sice se poměrně široce prosadilo, ale vedle něj vyrostly a celkem zdárně vegetují „z praxe vzešlé“ formáty jako třeba JSON. Technika AJAX se ve spoustě implementací mění v AJAJ (nahrazuje XML právě JSONem).

Důvod je pravděpodobně prostý: XML je ve spoustě případů příliš mohutný, rozsáhlý a „mocný“ nástroj – se všemi svými transformacemi, šablonami, jmennými prostory a dalšími možnostmi nabízí mnohdy víc, než web potřebuje. Stejně tak XSLT je bez debat velmi silný nástroj a dokáže udělat s daty v XML hotová kouzla. Rozhodně nechci zpochybňovat jeho schopnosti, možnosti či „právo na život“, rád bych ale přidal další úhel pohledu k tvrzení Jiřího Koska o „jazyku budoucnosti“.

Děsivý příběh z praxe

Před časem jsem se setkal s potřebou vyvinout „mashup“ nad Google Maps. Jako prostředí bylo dáno PHP a SQL databáze na dedikovaném serveru. Jelikož dodavatel v jiných projektech používal PHP+XSLT, bylo rozhodnuto, že pro vytváření výsledného HTML kódu a dat bude použito právě XSLT.

První problém nastal při testech XSLT na serveru. V PHP 5.2.5 totiž je jiná knihovna libxslt než ta, na níž byly odladěny firemní komponenty, a právě drobná změna syntaxe (default hodnoty u šablon) způsobila, že firemní komponenty nefungovaly. Bylo potřeba downgradovat na libxslt z verze 5.1.x (k velkému údivu a nelibosti provozovatele hostingu).

Zásadnější problém byla ale z mého pohledu obrovská neefektivnost práce s daty. Příklad: stránka s profilem uživatele. Skript pracoval s cca deseti hodnotami (ID uživatele, jméno, adresa, heslo, login, …), které zabíraly několik desítek bytů a byly načítány ze SQL databáze do PHP pole. Těchto pár položek bylo interně transformováno do podoby strukturovaného XML a předhozeno XSLT procesoru spolu se stokilovou šablonou (zápis šablon v XSLT není rozhodně úsporný, tam kde si ve Smarty vystačíme s {profil.jmeno}, tam v XSLT zapíšeme <xsl:value-of select="profil/jmeno" />). XSLT procesor vytvořil XHTML, to vrátil PHP procesoru a ten jej poslal klientovi.

XSLT tak bylo degradováno do role šablonovacího nástroje pro PHP. Do role, k níž se – a milovníci XSLT mi prominou – naprosto nehodí. Přečíst několik údajů z databáze a vložit je do HTML šablony není práce pro XSLT. Ne že by to nešlo – jde to, ale jsou rozhodně pohodlnější, rychlejší a efektivnější způsoby, které jsou určené přímo pro tento typ úloh.

XSLT jako šablonovací systém (třeba pro PHP)

Každý, kdo se setkal s několika šablonovacími systémy pro PHP, bude souhlasit s tím, že jsou navržené tak, aby oddělily kodéra od programátora. Kodérovi stačí znát jen „zástupné řetězce“, které budou ve výsledku nahrazeny konkrétní hodnotou, a jinak píše své (X)HTML. Nemluvě o tom, že šablonovací systémy umí takové věci, jako je např. kontextově závislé ošetření řetězců či možnosti použít cache u vložených šablon, což u XSLT sice jde taky zařídit, ale je třeba na to myslet, zatímco dobrý šablonovací nástroje to umí „na pozadí“. A to nemluvím o situaci, když je ve vstupních datech např. část URL pro obrázek. To, co ve Smarty zapíšeme jednoduše a přímočaře pomocí <img src="/obrazky/{profil.id}.jpg ... />, budeme v XSLT zapisovat konstrukcí s xsl:element… Pokud váš kodér není s XSLT jedna ruka (a to většina není), bude šablony muset přepisovat programátor z HTML do XSLT!

Pomíjím pak takové bonbónky, jako zápis entity &nbsp; v XSL šabloně (lze nahradit  ), zápis sekce CDATA tak, aby „probublala“ do výstupního souboru, nebo to, že při použití transformace „do XHTML“ převede procesor neprázdný element bez obsahu (typicky <script src=""></script>) na tvar <script />, na němž mnohé prohlížeče (např. Firefox) „zhavarují“ (považují jej za otevírací entitu). Hledání takových chyb je pak netriviální záležitost a alespoň pokud je mi známo, nelze je řešit jinak než nějakým hackem (u scriptu jsem používal vložené „ var dummy=0“). Možná, že jiné verze procesoru toto umí ošetřit. Opět: Ne že by to nešlo, jde to obejít, je potřeba na to jen pamatovat – ale přesto se nemohu zbavit dojmu, že tu člověk platí příliš vysokou daň, kterou by vhodnou volbou nástroje umenšil.

Navíc jsou dnešní webové aplikace plné situací, které právě naráží na výše zmíněné „zvláštnosti“ – vyžadují míchání JavaScriptu do HTML kódu (ne všechno lze načíst z externích .js souborů), na vstupu většinou mívají data coby objekt či asociativní pole (nemusí jít jen o výstup ze SQL – co třeba nonSQL databáze typu „klíč – hodnota“?), se situacemi, kdy je z velkého objemu dat generováno třeba PDF se člověk téměř nesetká, naopak je potřeba generovat např. malé XML/JSON soubory pro AJAX/AJAJ, je potřeba důsledně ošetřovat vstupy, je potřeba mít naprostý přehled nad vygenerovaným kó­dem…

Zkrátka, pro většinu současných webových aplikací NENÍ XSLT tím nejvhodnějším nástrojem. A to nejen v PHP, ale ani v dalších jazycích, které jsou používány pro vývoj webu – většina z nich používá vlastní šablonovací nástroje.

Je tedy XSLT špatné?

Nikoli. jen se pohled webových vývojářů na XSLT pohybuje, stejně jako XML zmíněné výš, po cestě do Úžlabiny deziluze. Čím dál víc vývojářů si uvědomuje, že bezhlavé používání XSLT všude možně jen proto, že jde o technologii budoucnosti, a to i v situacích, kde jeho použití není dvakrát vhodné, je cesta do pekel. Po obrovském nadšení z možností přichází vystřízlivění a zjištění, že XSLT není všespasitelné. To je naprosto v pořádku a přirozené; na druhou stranu by bylo krátkozraké XSLT zavrhnout an sich. Jiří Kosek má se svým bonmotem o „jazyku budoucnosti“ pravdu – ovšem v trochu jiném smyslu. Totiž: Až v budoucnu teprve XSLT najde svoje reálné místo, bez přehnaných očekávání i bez podceňování, a vstoupí na „planinu produktivity“.

Ponaučení pro dnešek je zřejmé: Než nasadíte XSLT jen proto, že je to „jazyk budoucnosti“, zkuste se zamyslet: Opravdu je jeho použití ve vašem případě vhodné? Opravdu vaše webová aplikace stojí a padá se sofistikovaným zpracováním XML souborů? Není na místě použít nějaký čistě šablonovací nástroj?

Pokud jste Jiří Kosek (nebo jiný XSLT hardcore hacker) a žádná záludnost XSLT vás nepřekvapí, jistě může být XSLT vaším šablonovacím nástrojem první volby. Pokud vyvíjíte high-end enterprise aplikace postavené na XML technologiích, tak taky asi není o čem diskutovat. Ale když hledáte vhodný nástroj pro šablonovou mezivrstvu do nějakého interaktivního webu, který stojí víc na dynamické práci s klientem než na zpracování XML dat ve velkých objemech, zvažte, zda je XSLT opravdu vhodné; zda šablonovací nástroj typu Smarty, Dwoo nebo Nette templates nebude pro váš účel vhodnější. Nemusíte používat XSLT jen proto, že je „in“, že ho používají „borci od bankovních enterprise aplikací“ a že má v názvu písmeno X!

Za použití šablonovacího nástroje se nemusíte stydět, stejně jako nejste automaticky king proto, že používáte XSLT. Důležité je nepodlehnout módní vlně (a už vůbec ne diskusím na webu) a v první řadě zvážit vhodnost toho kterého nástroje pro daný účel.

Ale to je snad samozřejmé, ne?

Začal programovat v roce 1984 s programovatelnou kalkulačkou. Pokračoval k BASICu, assembleru Z80, Forthu, Pascalu, Céčku, dalším assemblerům, před časem v PHP a teď by rád neprogramoval a radši se věnoval starým počítačům.

Komentáře: 28

Přehled komentářů

keff Díky!
VfB Re: Nechoďte s XSLT na vrabce!
SB Autor klame, alebo s XSLT nevie pracovat
smarty Re: Autor klame, alebo s XSLT nevie pracovat
karf Re: Autor klame, alebo s XSLT nevie pracovat
David Ondřich Re: Autor klame, alebo s XSLT nevie pracovat
mm Re: Autor klame, alebo s XSLT nevie pracovat
fos4 Re: Nechoďte s XSLT na vrabce!
karf Re: Nechoďte s XSLT na vrabce!
fos4 Re: Nechoďte s XSLT na vrabce!
karf Re: Nechoďte s XSLT na vrabce!
fos4 Re: Nechoďte s XSLT na vrabce!
karf Re: Nechoďte s XSLT na vrabce!
fos4 Re: Nechoďte s XSLT na vrabce!
karf Re: Nechoďte s XSLT na vrabce!
BurgetR Re: Nechoďte s XSLT na vrabce!
MD Re: Nechoďte s XSLT na vrabce!
fos4 Re: Nechoďte s XSLT na vrabce!
karf Re: Nechoďte s XSLT na vrabce!
fos4 Re: Nechoďte s XSLT na vrabce!
BurgetR Špatná technologie nebo špatné použití?
Tobi Re: Špatná technologie nebo špatné použití?
František Kučera Re: Špatná technologie nebo špatné použití?
Jiří Kosek Subjektivní názor: XSLT je super
Jan Kodera Re: Subjektivní názor: XSLT je super
Jarek Mikeš Re: Subjektivní názor: XSLT je super
HolyHop Nebo s tankem na maliny...
Kit XML jako mezičlánek mezi DB a XSLT?
Zdroj: https://www.zdrojak.cz/?p=3129