Přejít k navigační liště

Zdroják » Různé » Nechoďte s XSLT na vrabce!

Nechoďte s XSLT na vrabce!

Články Různé

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?

Komentáře

Subscribe
Upozornit na
guest
28 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
keff

Kdyby bylo pod článkem facebookovské „I like this“, nebyl by tu tenhle komentář :).

XSLT je opravdu silná věc, ale rozdíl mezi „akademickým“ a „inženýrským“ přístupem je v tom, že u inženýrského se často vyplatí zvolit technologii či algoritmus podle jiného kritéria než je asymptotická složitost při nekonečně velkém vstupu/velikosti projektu.

A jako se nikdo nediví že máme celou škálu jazyků, od .bat až třeba po C++ či Haskell, z nichž každý je vhodný na něco jiného, neměl by se divit ani že pro některé účely je XSLT super, a jinde zbytečně komplikované.

VfB

moc pěkně napsané, díky

SB

>> To, co ve Smarty zapíšeme jednoduše a přímočaře pomocí <img src=“/obrazky/{pro­fil.id}.jpg … />, budeme v XSLT zapisovat konstrukcí s xsl:element

XSLT pouziva rovnaky zapis, do atributu pomocou {} mozno zapisat lubovolnu premennu alebo XPath vyraz, cize zapis moze vyzerat takto:
<img src=„{/root/o­brazok}.jpg“ … />
Prave Smarty sa v mnohych pripadoch „inspiruju“ XSLT pristupom.

>> Pomíjím pak takové bonbónky, jako zápis entity   v XSL šabloně

Lubovolne entity pouzitelne v XSLT sa daju definovat cez DTD.

>> 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 />

Cisto otazka XSLT parsera. PHP ma tak vela moznosti, ako implementovat externy parser, no to by niekto musel prekonat lenivost a prestudovat si dokumentaciu.

>> Zkrátka, pro většinu současných webových aplikací NENÍ XSLT tím nejvhodnějším nástrojem.

Zavadzajuce a klamlive tvrdenie. Kto si XSLT nenastuduje, ten ho samozrejme pouzivat nikdy nebude vediet tak, aby bolo efektivne (co plati pre vsetky programovacie jazyky). Ja pracujem primarne ako .NET a PHP programator a mozem zodpovedne prehlasit, ze XSLT je pravdepodobne najlepsi nastroj na riesenie sablon a na pracu s XML vobec. Subjektivny nazor autora je prejav nepochopenia fungovania XSLT.

>> Za použití šablonovacího nástroje se nemusíte stydět

Ale ANO! Keby mi vo firme uchadzac o pracu predviedol SMARTY, vysmejem ho. Uroven pouzivaneho nastroja pre sablonovanie == zvycajne uroven programatora.

smarty

Mozna Pro Vas hloupa otazka, ale co je na SMARTY tak extremne spatneho ? Urcitou dobu jsem ho docela casto vyuzival a nenarazil jsem na zasadni problemy, nebo mi neco uniklo ?

karf

Že by tím, jak se hojně inspirují XSLT přístupem? (sorry, nemohl jsem odolat :)

David Ondřich

Prave Smarty sa v mnohych pripadoch „inspiruju“ XSLT pristupom.

Jako milovník Perlu bych (poměrně úspěšně) mohl oponovat, že „XSLT pristup“ je ve skutečnosti okopírovaná perlovská syntaxe HERE doc, ale nešť.

Cisto otazka XSLT parsera. PHP ma tak vela moznosti, ako implementovat externy parser, no to by niekto musel prekonat lenivost a prestudovat si dokumentaciu.

Ve chvíli, kdy je v některé z knihoven parseru chyba a vy nemáte možnost to opravit, jste v rejži. Na webu (na skutečném webu, ne v intranetu, kde máte vše pod kontrolou) to je docela častá situace. Jednoduchý šablonovací nástroj, který přilinkujete ke své aplikaci, pak vítězí na celé čáře. Nemluvě o tom, že bude pro jednoduché úkoly pravděpodobně rychlejší.

Ostatně, když jste ten .NET programátor, jistě víte, že třeba v MSXML knihovně byly některé závažné chyby opravené až ve čtvrté verzi (po dvanácti letech existence).

Subjektivny nazor autora je prejav nepochopenia fungovania XSLT.

Váš komentář mně naopak připadá jako projev (vašeho) nepochopení, o čem ten článek vlastně je.

mm

XSLT ja sablonovaci system pro web je uchylka a toho kdo to vymysli bez milosti poravit. Smarty moc nemusim, ale oproti XSLT je to pohoda. Vynikaji je kdyz krome XSLT nic jineho k dispozici nemate a tak vysledek priohybate javascriptem v prohlizeci parada.

Na druhou stranu XSLT s chuti pouziji k transformaci XML kde mi par radek nahradi desitky radek kodu.

Proste XSLT se ma pouzivat tam kde patri, ale rozhodne ne jako website frontend technologie. Fuj…

fos4

Patrim k tem XSLT milovnikum, kteri si nedokazou sablonu / transformaci XML → XML/(x)HTML/atd. predstavit bez XSLT. Autor narazi na slozitost vytvoreni tagu img, zkraceni scriptu apod. Oboji lze snadno zapsat, staci vedet jen „jak na to“:

<img src=„/obrazky/{pro­fil.id}.jpg />
to v XSLT jde temer stejne:
<img src=“/obrazky/{pro­fil/id}.jpg />
Dále <script> – pri spravnem pouziti xsl:output toto bezi naprosto v poradku.

Clanek moc pekne napsany, je jasne ze XSLT se hodi na urcite ulohy, ale treba generovat JSON bych pomoci XSLT nechtel delat (ale ty dva priklady jsem napsal musel:)

karf

Který XSLT procesor umí správně xsl:output=„xhtml“ se všemi zvláštnostmi? Kdysi jsem takový hledal a nenašel.

Jinak ve webových aplikacích primárně nejde o transformaci XML → něco, takže XML a XSLT je zde jakási zbytná mezivrstva. Ale všechno je vlastně krásně popsané v článku výše, k tomu asi není potřeba nic dalšího dodávat.

fos4

<xsl:output
method=„xml“
indent=„yes“
encoding=„UTF-8“

doctype-public=„-W3CDTD XHTML 1.0 Transitio­nalEN“
doctype-system=„http:
http://www.w3.org/…/xhtml11.dtd
/>

Primarne jde o XML ⇒ HTML a to XSLT resi krasne, stejne tak i dalsi transformace (samozrejmne ne vsechny).

U XSLT sablony se posila XML u ostatnich klasicke promene, takze bych mohl rici ze zbytna mezivrstva je i tu. Proc tedy vubec pouzivat sablony ze ?

karf

1) Tak tohle nevyplivne XHTML „se všemi zvláštnostmi“ ani náhodou :) XSLT norma (teď nevím ve které verzi, ale tuším že snad už i v 1.x) zavádí jednu z výstupních metod „xhtml“, která by toto měla řešit. Právě proto, že „xml“ ani „html“ pro XHTML nevyhovuje.

2) Možná pracuju s netypickými webovými aplikacemi, ale co já znám, tak jde většinou primárně o to, načíst data ze SQL databáze, něco málo s nimi programově udělat a vygenerovat výstup v podobě (X)HTML. Nikde v tomto řetězci se XML reprezentace dat implicitně nepředpokládá.

fos4

1) XSLT 1.0 a vyse uvedeny output nam funguje, ale treba nepouzivame „zvlasnosti“, jake vubec mate namysli ? (xhtml nelze pouzit – jak jste psal)

2) Vam je proti srsti poslat sablone XML pripadne at si si sablona tvori XML ze vstupnich promenych a nakonec provede transformaci ?
Mne to prijde stejne jako kdybychom se bavili o databazovem layoutu a vy tvrdil ze je zbytecny, ze si clovek vystaci se zakladnimi funkcemi a neco mezitim je zbytecne. Pokud to ulehci, zefektivni praci proc to nepouzit.

karf

1) To jsou ty nechvalně proslulé zvláštnosti, aby mohl být XHTML dokument zpracováván jak HTML parserem v prohlížeči, tak i XML parserem. Čili že některé prázdné elementy se zapisují s ukončovací značkou, jiné bez, mezera před ukončovacím lomítkem, atd.

2) Mně to ani tak proti srsti není, já mám XML a XHTML celkem rád, ale problém je v tom „pokud to ulehčí a zefektivní práci“ – mé zkušenosti ukazují opak. Ale nevylučuju, že u jiných případů tomu tak může být.

fos4

Tak vsechny tyhle zvlasnosti nam prave funguji (jednou davno jsme s tim meli problem,uzaviral se tag script a textarea, ale to prave vyresil output se spravnym doctypem). Nevim jestli to u starsich verzich libxslt dela neporadek, ale nam to uz nejakou dobu funguje (v PHP).

Moje zkusenosti zase ukazuji ze XSLT je vyborna volba.

karf

Ech, mělo tam být „já mám XML a XSLT celkem rád“ :)

BurgetR

ad 1) XHTML právě žádné takové zvláštnosti nemá. Má úplně normální XML syntaxi včetně těch prázdných značek. Nebo mi něco uniká? Co se v XHTML musí zapsat v rozporu s XML syntaxí? (kromě toho, že zastaralé prohlížeče nerady úvodní XML deklaraci?)

MD

<br /> misto <br/>

fos4

xslt vygeneruje

Jinak spravny zapis xhtml je ten jak jsem psal, output type xhtml je hloupost…

karf

Tak jsem se dostal k tomu, abych to otestoval s aktuální verzí PHP. Projel jsem některé svoje starší šablony a máte pravdu – nyní se to podle nastaveného XHTML doctypu chová zdá se korektně (jestli se dá o „XHTML syntaxi“ říct, že je korektní :). Čili co jsem psal už dnes zjevně neplatí, díky za nakopnutí.

Jinak ten atribut „xhtml“ hloupost není, skutečně má v některých procesorech za následek onu xhtml serializaci (např. saxon jej jaksi podporuje).

fos4

Nejak to nezobrazilo. takto to vygeneruje:
<br />

BurgetR

Už z názvu XSLT: předpokladem pro jeho použití je obvykle mít nějaká data v XML. To se v dnešní době může snadno stát – data z jiné aplikace, RSS zdroj, existují i XML databáze. Pak vám XSLT pro některé úlohy výrazně zjednoduší práci a umožní přesunout vhodné věci do šablon. Na to samozřejmě také existují příklady z praxe. Do klasické „oldschool“ kombinace SQL+PHP+HTML opravdu stěží zařadíte XSLT tak, abyste si to celé nezkomplikovali. Takže bych místo „Nechoďte s XSLT na vrabce“ bych spíše napsal „Nepoužívejte XSLT blbým způsobem na blbém místě“. Ostatně by to šlo zobecnit.

Tobi

Souhlas;-)

František Kučera

+1 Takhle to dopadá obvykle, když člověk chce (nebo je mu to nařízeno) používat moderní technologii a přitom není schopný se vymanit ze svého obvyklého způsobu práce. Technologii tam nakonec napasuje, ale je to na draka.

Jiří Kosek

Asi se čeká, že sem do diskuse něco napíšu, že? ;-)

Předně – pro řešení problému je potřeba vždy využívat nejen správný nástroj, ale i nástroj, který vývojář umí používat. Takže pokud nějaký projekt volá po použití XML/XSLT, ale vývojář technologii neovládá, nedopadne to dobře. Podobně, i kdyby vývojář byl mistr světa v XSLT, ale použije jej na místě, kde se to nehodí, nedopadne to dobře. Ale to asi každý tuší.

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“

Ten článek byl o tom, jak se dá z PHP volat XSLT. XSLT se v něm nijak nevychvaluje, to by vypadalo o dost jinak. Je to spíše srovnání s ostatními XML API v PHP.

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.

Tak to ale nebude problém XSLT. XSLT 1.0 je na světě od roku 1999, existuje více než 10 masově používaných implementací jazyka a ty mezi sebou mají velice dobrou interoperabilitu. Maximálně to může být problém v PHP API pro volání XSLT, ale těžko z takhle vágního popisu problému usuzovat.

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/jme­no“ />). XSLT procesor vytvořil XHTML, to vrátil PHP procesoru a ten jej poslal klientovi.

Za špatně postavenou architekturu aplikace ale jazyk XSLT nemůže. Proč nebyla data rovnou vrácena z databáze jako XML? Proč se pro práci s daty nepoužívalo API, které umí jedny data duálně reprezentovat jako sadu záznamů i strom XML?

Jinak pokud se ve zmíněném případě XSLT transformace starala o vložení pár položek do nějakého mustru HTML a měla sto kilo, tak sto kilo musel mít i ten samotný HTML kód – do XSLT se HTML kód vkládá přímo bez escapování. Velikost XSLT kódu tak musela být srovnatelná se Smarty šablonou.

XSLT má navíc od různých primitivních šablonovacích systémů výhodu v tom, že to je standardizovaný jazyk. XSLT tak můžete volat z jakéhokoliv jazyka. Není tak nutné po změně jazyka, ve kterém je psané jádro webové aplikace, měnit šablonovací systém. Pro XSLT existují vizuální návrháře výstupních sestav – pokud to někomu vyhovuje, vše jen natahá a nakliká myší. Nevím o tom, že by něco podobného existovalo pro běžné šablonovací systémy.

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

Jiní už napsali, že vše o čem se v té sekci píše, lze v XSLT vyřešit celkem elegantně, pokud člověk XSLT zná.

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“.

Asi se pohybuji v jiném světě, ale znám mnoho lidí, co už jsou na té „planině produktivity“ s XSLT 8 a více let ;-)

Za použití šablonovacího nástroje se nemusíte stydět,…

Za to se jistě nikdo stydět nemusí. Ale rád bych všem připomenul, že v článku zmiňované PHP bylo navrženo a pořád je šablonovací systém. Pořád mi tak připadá poněkud perverzní psát v šablonovacím systému PHP interprety a kompilátory jiných šablonovacích systémů, které toho umějí méně. ;-)

Ve webových aplikacích jako jednu z výhod použití XSLT vidím snazší rozdělení aplikace do vrstev. Použití XSLT vás donutí si mezi vrstvami aplikace předávat data v XML a máte tak jasně definované rozhraní. Jednotlivé vrstvy aplikace jsou tak na sobě nezávislé, je snazší, když je píší různí lidé, jde snadno zaměnit technologii, ve které jsou naimplementované, …

Podle mne má cenu buď psát aplikace elagantně, rozdělené na vzájemně relativně nezávislé vrstvy a na to se XML/XSLT hodí (ale lze toho samozřejmě dosáhnout i jinými prostředky), nebo aplikace zcela záměrně „prasit“ – vytáhnout si data z databáze a rovnou je pomocí <?php echo ?> vysypat do HTML. Ale ta řešení něco mezi mi připadají tak napůl cesty, nešťastně kombinují nevýhody obou přístupů.

Jan Kodera

Tou prací ve vrstvách myslíte, že data mám v xml databázi, ty jako xml předám xslt, které provede nějakou business logiku a pak to šoupne další xslt které z toho nadělá html výstup? Příklad takového přístupu by jistě byl vhodný jako článek :)

Problém použití XML je v tom, že je moc písmenek použito k popisu dat. A to u webové aplikace, která očekává že bude navštěvovaná problém je. To je asi podobná situace jako když, twitter musel opustit ruby neboť hardware začínal být dražší než programátoři.

Přesto to vypadá, že si s XML ještě užijeme, protože protokol nejnovější hype Google Wave využívá XML, minimálně k zapsání změn ve wave. Což je zajímavé, pamatuji si, jak v dobách SOAP, programátoři zjistili, že posílat si skrze XML malé změny není zrovna nejlepší nápad. A to je přesně co wave dělá. Že by to byl důvod, proč tam tak pomalu pouští lidi? :)

Link jak donutit MySQL aby vracela XML http://eriksdiary.blogspot.com/…m-mysql.html

Jarek Mikeš

Tím je myšleno, že XML tvoří jen jakousi datovou mezibránu. Data jsou v obyčejné databázové formě (MySQL, SQL, atd.), pomocí jazyka data (PHP, ASP, JAVA) z DB vytáhnete, vygenerujete XML dle nějakých norem a schémat XSD (a nebo taky jen XML od boku a na slepo bez validace) pak XML pošlete přes XSLT transformaci a pomocí XSL šablony vygenerujete patřičný výsledek do HTML/XHTML výstupu.

Ač to zní velice zdlouhavě, z praxe musím říci, že mám projekty s tisíce požadavky za vteřinu a tento proces funguje bezproblémově a rychle. A vždy když začnou být problémy můžete popisované procesy přeskočit např. cachováním některých mezivrstev.

XSLT používám 6 let a musím říct, že je to luxus na který jsem si velice rychle zvykl. (zkoušel jsem spousty jiných šablonovacích jazyků a bylo to zlo).

Navíc XSLT je výhodné pro vývojářské společnosti, kde máte rozvrstvené i výroby projektů na jednotlivé profese. Potom např. webmaster/koder bez nutných znalostí OOP je pomocí XSL šablon schopen jednoduše rozjet různé výstupy aniž by měl přístup do té aplikační vrstvy nad samotnou šablonou.

HolyHop

Každý si bude asi obhajovat svoje stanovisko ať už pro či proti. Osobně proti XSLT vůbec nic nemám, ba naopak, v jistých případech ho i používám, ale zrovna jím nahradit šablony, do toho bych zatím nešel.

Já za sebe při vývoji tlačím na maximální jednoduchost. Opravdu nemám rád obludné mnohatisíciřádkové superuniverzální řešení, které myslí na všechno možné, ale když potřebujete něco co obludné řešení neobsahuje musíte hledat, jak celý superuniverzální systém obejít..

Takových superuniverzálních systémů jsem už i pár stvořil, pár doslova, po čase jsem zjistil, že skvělá věc kde můžete cokoliv nadefinovat pomocí XML je spíše na zabití a to obzvlášť v případě kdy nakonec reálně slouží pouze na jednom jediném projektu pro jeden jediný případ a ač se zdála po vystavění sebeinteligentnější a sebelepší je po půl roce na houby a ke vzteku kolegů.

Spíš než se hádat jestli je XSLT jazyk budoucnosti či nikoliv, bych doporučil zevrubně nastudovat a zvážit, jestli XSLT vaše hlava dokáže zapracovat do modelu aplikace tak, aby jste byli na pláních fachability a ne jen bastlili dalsi jazyk nad jazykem.

A přiznám se, že XSLT mi do mého modelu zatím nesedí a přijde zbytečné. Uvidíme za rok dva…

Kit

Čtu tady v příspěvcích, že někdo data v PHP po vybrání z databáze převede do XML a teprve pak je pustí do XSLT. Ten mezičlánek se dá vypustit tím, že data z DB nasypu přímo do stromu třídy DomDocument a ten nechám transformovat přes XSLT.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.