Názory k článku
Generujeme jednoduchý web pomocí XML

Jen víc takových!

http://www.php.net/manual/en/xsltprocessor.registerphpfunctions.php ?

Sila XSLT sa prejaví práve pri použití vo veľkých dynamických weboch, na ktorých v jednom momente môže pracovať viac developerských teamov. XSLT v MVC architektúre nájdeš v mnohých komplexných business riešeniach.

Na co se více hodí PHP použij PHP, na co více XSLT použij XSLT.

Na velke weby se práve XSLT nejvíce hodí, jedna část týmu se věnuje programování kde výstupem je XML a to už si převezmou kodeři a jen píší XSLT + CSS + JS.

Mimo jiné ještě existuje XSLT2 (http://www.w3.org/TR/xslt20/), případně pro PHP exslt (http://www.exslt.org/)

Ale jsi zlý :-D

Ale no tak. XSLT je dobrý nástroj třeba v situacích, kdy je třeba generovat několik různých výstupních formátů pro jeden dokument - třeba plain a html part nějakého automaticky generovaného mailu - tam má koneckonců podobná transformace nezastupitelnou roli vzhledem k tomu, jak jsou MUA nejednotné a pitomé při zobrazování rich textu.

Když někdo zmiňuje milion "jiných a vhodnějších" nástrojů, očekával bych, že přihodí nějaký odkaz na stránku se srovnáním některých těch "jiných a lepších" s kritizovanou technologií.

Ač ručně psané XML nemám rád, tak na strukturovaný přenos _generovaných_dat_ to tak špatné není. A deklarativní způsob programování je mi také docela blízký, takže bych deklarativní pattern matching transformační jazyk rozhodně za slepou uličku nepovažoval..

Ale zajímalo by mě jaký je tedy jiný, jednodušší a vhodnější nástroj na _obecnou_tran­sformaci_ strukturovaných dat? (Protože třeba převod z docbooku do html|LaTeXu|.. je docela příjemný proces).

A tenhle podle vás nejpříšernější programovací jazyk má v sobě zabudovaný velice mocný dotazovací jazyk nad datovým modelem, se kterým pracuje. To je pro složitější transformace naprosto klíčová věc. Jazyků, které tohle mají moc není a v těch co to mají (včetně XSLT) napíšete transformace mnohem úspornějším způsobem -- to vám asi přijde příšerné, že?

jak se tam dá zpracovat xml Mixed Content?

XSLT je DSL šitý na míru určitému typu problémů. Srovnávat jej s jakýmkoliv GPL nedává moc smysl. XSLT samozřejmě nikdo nebude používat namísto běžného jazyka, ale na druhou stranu nelze říci, že alternativou k němu je třeba C++ nebo Java, rozhodně ne bez nějaké srovnatelně mocné knihovny. To by bylo jako srovnávat pilník se soustruhem, nebo ne?

Aby vás někdo bral vážně, asi by bylo dobré zmínit alespoň pár z těch milionu vhodnějších nástrojů.

A vzhledem k tomu, že se pracuje na XSLT 3.0 bych to na slepou uličku neviděl.

Ale o tomhle dotaz nahoře není - abych se přiznal, také by mě zajímaly nějaké příklady - nemusí jich být milión, ale alespoň něco...

P.S. touhle etapou jsme si už snad prošli, ne?

Ach, jo, cenzura...

důležitý byl ale význam příspěvku a za tím si stojím:

"zatimco s FP to zvladne ... i absolvent/ka pajdy po par hodinach zacviku."

Ano, weby může dělat každý, ale z takovéhoto softwaru lezou lezou exkrementy, na které ostatní narážejí na webu. Touhle etapou jsme si už snad prošli, ne? Jistým pokrokem byl nástup redakčních systémů, které kontrolují vstup a/nebo formátují text na základě nějaké syntaxe typu BB nebo wiki.

od prvního dubna uplynul více jak měsíc!

Front Page je jen o něco lepší Word (myšleny stránky vygenerované v MSO)

Ehm, a da se vystup z toho uzasnyho nastroje taky nekde zobrazit? Co jsem mel tu cest, tak to nefunguje ani v IE.

tak to nevím, co jste v tom Front Page napáchal ale pokud si pamatuji, tak nějaký výstup jde ve Front Page vytvořit, dokonce se takové stránky zobrazí ale kód je prasárna

XHTML2 narozdíl od XSLT 3.0 nemělo žádné implementace -- a to je také to na čem zkrachovalo.

Proč nepoužít přímo programovací jazyk, v němž píšu celou aplikaci?

Například proto, že na výstupu transformace typicky generujete HTML nebo XML a ve všech jazycích kromě XSLT a XQuery se musí generované fragmenty HTML/XML escapovat nebo generovat pomocí příkazů typu print, nebo různých markup builderů -- nejde použít nejoblíbenější návrhový vzor mnoha vývojářů (prosté copy'n'paste).

U složitějších transformací vám pak bude chybět mocný dotazovací jazyk a mechanismus automatického průchodu stromem dokumentu a výběru nejvhodnější šablony pro zpracování.

Například lispovské jazyky tu byly dříve než SGML a vcelku dobře se v nich pracuje se stromovými strukturami.

Historie ukázala, že tudy cesta nevede. Předchůdcem XSL byl jazyk DSSSL, což je Scheme s pár věcmi navíc, a i když z čistě teoretického hlediska bylo DSSSL dokonalejší než XSLT (minimálně XSLT 1.0), DSSSL se používalo a používá minimálně.

A misto databazich budeme pouzivat knihovni psane v jazyce v jakem je psana aplikace. Protoze tam je "neco podobneho taky mozne".

Transformace XML -> ? je XSLT velmi jednoducha oproti jinym jazykum, nebot XSLT obsahuje XPath a dalsi funkce ktere by se v jinym jazycich museli nejak simulovat, zkuste si to...

Můžeš mi prosím napsat nějaký příklad dotazu v SQL a v „jazyce, ve kterém píšeme aplikaci“? Takové ORM často umožňují používat kromě dotazovacího jazyka (jako JPQL) i zápis pomocí objektově orientovaného jazyka (ve kterém je zbytek programu), takže člověk pak místo psaní dotazu volá několik metod, ale přehlednější nebo přívětivější mi to moc nepřijde (s výjimkou dynamicky tvořených dotazů). To je dané tím, že ten programovací jazyk je univerzální, kdežto dotazovaný jazyk je šitý na míru danému úkolu (dotazování, výběr dat).

Pár jednoduchých příkladů pro C# je v následujícím článku:

http://www.hookedonlinq.com/LINQtoSQL5MinuteOverview.ashx

Pár příkladů, co umí VB (tohle není nutně jen pro SQL):

http://msdn.microsoft.com/en-us/library/bb763068.aspx

Hlavní výhoda je, že LINQ mohu použít pro dotazy do objektů v programu (například kolekcí), do XML, do SQL a do Entit. A mohu ho použít i k transformacím.

Dík, tohle mi stačí:

where c.DateOfBirth.AddYears(35) > DateTime.Now

A to se vám nelíbí nebo naopak líbí?

Co takhle odečíst 35 od aktuálního data (jednou) místo přičítání ke každému záznamu/objektu ;-)

Já vím, že to jde :-) Ale šlo mi o tu přehlednost, srozumitelnost – a tady podle mého pořád vede deklarativní programování nad imperativním.

Například Visual Basic to podporuje a Scala také:

Nechce se mi studovat gramatiku VB.NETu a Scaly, tak se zeptám -- lze uvnitř XML literálu používat veškeré další jazykové konstrukce -- zejména podmínky a cykly, které opět mohou generovat XML literál?

Tohle lze vyřešit v rámci knihovny.

No chtěl bych vidět knihovnu, která s rozumně použitelnou syntaxí nabídne funkce obdobné xsl:template včetně režimů, priorit a věcí jako xsl:apply-imports nebo xsl:next-match.

Cele mne to prijde jako zbytecna debata, vy na rikate ano je to dobry ale proc to neudelat v necem jinem nebot to tam jde taky udelat.

XSLT je primo na tyto ucely vytvoreno a vyladeno a vsechny ficurky co vam dovoluje jen horko tezko zkousi dohanet ruzne knihovny v ruznych programovacich jazycich.

XSLT je primo na tyto ucely vytvoreno a vyladeno a vsechny ficurky co vam dovoluje jen horko tezko zkousi dohanet ruzne knihovny v ruznych programovacich jazycich.

• jednoduché dotazy/transformace napíšu rychleji a bude to kratší než v XSLT
• transformace/dotazy mohu parametrizovat celými funkcemi, třídami nebo moduly
• k dispozici je řada knihoven, mohu se například připojit k databázi, použít složitější validační mechanismy (mj. jak se v XSLT validuje e-mail) nebo generovat data v jiném formátu (co když budu z XSLT generovat SQL dotazy, bude mi schopen XSLT procesor garantovat, že vygenerované dotazy jsou platné?)
• nemusím se učit další jazyk
• na určité typy zadání je XSLT a XQuery absolutně nevhodné

• jednoduché dotazy/transformace napíšu rychleji a bude to kratší než v XSLT
  - nebude, ve valné většine XSLT vyjde lépe
• transformace/do­tazy mohu parametrizovat celými funkcemi, třídami nebo moduly
  - XSLT ma templates, promene, parametry atd.
• k dispozici je řada knihoven, mohu se například připojit k databázi, použít složitější validační mechanismy (mj. jak se v XSLT validuje e-mail) nebo generovat data v jiném formátu (co když budu z XSLT generovat SQL dotazy, bude mi schopen XSLT procesor garantovat, že vygenerované dotazy jsou platné?)
  - validace se da provadet na vstupnim XML - a tady je moznosti na validaci spousty, DTD, relaxNG..., mimo jine je tu i moznost volat fce daneho jazyka primo z XSLT ale to uz jina..
• nemusím se učit další jazyk
  - to nemusis
• na určité typy zadání je XSLT a XQuery absolutně nevhodné
  - stejně tak jako i jine jazyky

Ad "jak se v XSLT validuje e-mail"

Regulárním výrazem jako všude jinde. Případně si napsat vlastní rozšíření, pokud chce člověk dělat ptákoviny typu kontrola MX záznamů nebo dokonce naavzování SMTP spojení (blbost).

Ad "co když budu z XSLT generovat SQL dotazy, bude mi schopen XSLT procesor garantovat, že vygenerované dotazy jsou platné?)"

Který jazyk (kromě procedurálního/SQL jazyka daného SŘBD) ti tohle zaručí? Možná tak nějaké ORM jako je JPA.

A co se týče SQL - některé lepší DB umí vrátit výsledek ve formě XML - tam je XSL transformace ideální, člověk nemusí řešit překlad dat na objekty a zase zpátky

Ad "nemusím se učit další jazyk"

Totéž lze říct o XSLT - kdo umí HTML, ten se naučí pár řídících konstrukcí a může začít psát první transformace -- naučit se úplně jiný jazyk je většinou víc práce.

Ad "na určité typy zadání je XSLT a XQuery absolutně nevhodné"

To lze říct o každém nástroji

Ad "To generování stačí zabalit do nějakého builderu, který nedovolí postavit neplatné dotazy."

Abys měl jistotu, potřebuješ ovladač/knihovnu pro konkrétní SŘBD a stejně to nestačí -- abys měl jistotu, že dotazy jsou OK, potřebuješ i konkrétní datový model, nad kterým se budou pouštět. Tohle žádný "builder" nedokáže, protože nemá dostatek informací (a nedokonalý "builder" jde napsat i v tom XSLT)

Ad "jste omezen na velmi úzkou množinu věcí, které tam lze rozumně udělat."

Více méně ano, ale to (relativně) úzké zaměření je výhoda oproti univerzálním nástrojům. A v oblasti dotazování je XQuery hodně silný jazyk.

použití "industrial grade" technologií něčem "malém".

Osobně třeba Ant nemusím, ale jinak je tandem XML/XSLT dobrý tam kde jsou data přirozeně získávána z různých zdrojů a prezentována v různych souvislostech.

Já takhle pár svých menších webů (tvorbou webů se jinak nezabývám) udržuji a naprosto mi to vyhovuje. Není třeba instalovat další frameworky, stačí xslt procesor, a v kombinaci s CSS a trochou javascriptu je to přesně co mi vyhovuje - umožňuje čisté oddělení dat od obsahu, a mix obecných patternů s lokálním ručním doladěním (x)html kódu.

Díky za popularizační článek a té, pro mne ne moc pochopitelné zášti některých "webařů" si nevšímejte!

Samozřejmě psát si na malý web o pár stránkách "vlastní redakční systém" v XSLT je trošku přehnané. Na druhou stranu příklady pro článek nemůžou být nějaké extra složité, pokud má mít článek rozumný rozsah a někdo ho má číst.

Pokud snad někteří z těch, co zde dříve projevili extrémní nechuť nad XSLT, mají přece jen hlavu otevřenou, možná se můžou zamyslet nad tím, jak by se v jejich oblíbených nástrojích dělaly úlohy typické pro XSLT, např.:

Mám strukturovaný dokument v nějakém XML formátu (např. DocBook) a potřebuji z něj vygenerovat statický web včetně obsahu, odkazů, číslování objektů, rejstříku, ...
Něco jako http://www.kosek.cz/xml/xslt/

Mám v XML nějakou komplexní datovou strukturu (např. kompletní informace o studijním systému nějaké školy) a potřebuji z toho udělat web, něco ve stylu http://studijniplany.amu.cz/

Mám rozsáhlou kolekci článků v XML a potřebuji to dát na web, např. http://www.balisage.net/Proceedings/index.html

Řekl bych, že znám poměrně mnoho nástrojů, ale pro takovéto úlohy mi XSLT přijde jako nejvhodnější nástroj.

Nadruhou stranu chápu nechuť některých pro XSLT -- v praxi jsem už viděl tolik špatných příkladů použití XSLT, kdy to psal nějaký člověk, co vůbec nepochopil základní principy jazyka. Ale to je klasický problém -- když někdo používá technologii, kterou dobře neovládá, nedopadne to dobře. Ale není to chyba technologie, ale té osoby mezi klávesnicí a židlí.

Začít se dá s málem a učit se postupně - pokud jsem článek dobře pochopil, tak generátor je v podstatě hotový nástroj a uživatel ho může hned použít + si případně dopíše nějaké to makro nebo upraví šablonu.

Nicméně pokud se někdo chce seznámit s xslt tak je tohle myslím docela přístupná cesta, vyzkoušet si novou technologii ve spojení s něčím co už zná jinak (tvorbou jednoduchého webu)....

Proto je to nejspíš svobodný software - aby to mohl používat i ten, kdo si to sám nenapsal, ne?

A skutečně je to minomet? Ta XSL šablona je z velké části totožná s výstupním dokumentem – ve kterém jsou sem tam značky, co se má vložit ze vstupu. To samozřejmě umožňují i jiné šablonovací nástroje, jenže v nich se šablona typicky plní daty ve formě objektů daného programovacího jazyka – což je na jednu stranu fajn, na druhou stranu těžko se tam míchá text a značky a těžko se tam udělá to, co jsem tady nazval „makra“. Proto jsem zvolil XSLT. Navíc ty objekty (nic proti OOP) musí člověk někde vzít, znamená zase nějakou deserializaci/ma­pování z tvaru, ve kterém jsou data v souborech na disku.

Mimochodem, castecne (ne kompletni specifikaci) umi transformace primo napriklad firefox => posle se mu xml + xsl a on to aplikuje. Vyhoda toho je, ze uzivatel ma k dizpozici primo netransformovana zdrojova data a muze snimi tedy nalozit dle libosti. S vyhodnou pouzitelne napriklad pro rss - pokud prijde na stranku s rss nekdo bez ctecky, zobrazi se mu to "nejak hezky" (pokud to jeho prohlizec umi, samozrejme), pricemz ctecka proste pouzije jen ta data a transformacni sablona ji nijak nevadi.

Naprosto idealni je to pak pro ruzne statistiky - napr hernich serveru, kde vznikaji vsemozne weby hracu, kteri si chteji na svuj web vytahnout trebas sve vysledky/informace o postavach/... nemuseji pak parsovat hnusne html, ktere se navic muze menit.

ukladani vetsich dat do xml dokumentu nasadili na mff lingvistice pred lety
a prineslo to podle meho tyhle nevyhody:

1] vetsi velikost souboru
2] pomale dotazovani, pametova narocnost: treba ziskat slovnikove heslo ze slovniku; tehdy neexistoval eXist, ale stejne, jak si i dneska stoji v porovnani s zaindexovanymi daty v sql?
3] xslt je v jadru pattern matching - vidim vyhody jako optimalizace na rychlost zadarmo atd, ale vsechny moje sablony jsou dneska nepouzivane, protoze se vyvojem formatu vstupnich dat je proste nikdo neumi aktualizovat, xslt sablona je z definice obtizne prepouzitelna, pokud Vam nekdo zasadne zamicha se vstupem pisete novou. xstl je snad jeste vice write-only nez perl
4] pouzit off-shelf nastroje na xml predavane socketem taky nejde, vsechny knihovny buffrujou, prijde msg a oni cekaji az se naplni buffer! ke vsemu xml data musi mit jeden root element - coz ma mozna smysl u dokumentu ale u protokolu jako jabber uz me to teda netesi.

XML je skvělý pro komunikaci, předávání dat z jednoho systému do jiného, pro konfiguráky nebo dokumenty (docbook atd.), ale pro ukládání dat, jako náhrada databáze, je to otázka -- tam hodně záleží na struktuře dat a jejich variabilitě. Ačkoli mám XML hodně rád, musím říct, že většinou je pořád nejlepší volbou relační databáze.

Informace o dvou novinkách v mém blogu: XML Web generátor – práce pokračuje.

Právě vyšla nová verze: XML Web generátor – verze 0.3.