28 komentářů k článku Nechoďte s XSLT na vrabce!:

  1. keff

    Díky!

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

  2. SB

    Autor klame, alebo s XSLT nevie pracovat

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

    1. smarty

      Re: Autor klame, alebo s XSLT nevie pracovat

      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 ?

      1. karf

        Re: Autor klame, alebo s XSLT nevie pracovat

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

    2. David Ondřich

      Re: Autor klame, alebo s XSLT nevie pracovat

      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.

    3. mm

      Re: Autor klame, alebo s XSLT nevie pracovat

      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…

  3. fos4

    Re: Nechoďte s XSLT na vrabce!

    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:)

    1. karf

      Re: Nechoďte s XSLT na vrabce!

      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.

      1. fos4

        Re: Nechoďte s XSLT na vrabce!

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

        1. karf

          Re: Nechoďte s XSLT na vrabce!

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

          1. fos4

            Re: Nechoďte s XSLT na vrabce!

            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.

            1. karf

              Re: Nechoďte s XSLT na vrabce!

              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.

              1. fos4

                Re: Nechoďte s XSLT na vrabce!

                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.

              2. BurgetR

                Re: Nechoďte s XSLT na vrabce!

                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?)

                  1. fos4

                    Re: Nechoďte s XSLT na vrabce!

                    xslt vygeneruje

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

                    1. karf

                      Re: Nechoďte s XSLT na vrabce!

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

  4. BurgetR

    Špatná technologie nebo špatné použití?

    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.

    1. František Kučera

      Re: Špatná technologie nebo špatné použití?

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

  5. Jiří Kosek

    Subjektivní názor: XSLT je super

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

    1. Jan Kodera

      Re: Subjektivní názor: XSLT je super

      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

      1. Jarek Mikeš

        Re: Subjektivní názor: XSLT je super

        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.

  6. HolyHop

    Nebo s tankem na maliny...

    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…

  7. Kit

    XML jako mezičlánek mezi DB a XSLT?

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

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3129