Starší komentáře ke článku: Kompletní průvodce XSLT - proměnné a parametry
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 8.7.2004 9:42:34
Nechi rejpat, ale věta "Naštěstí v XML procesorech společnosti Microsoft existuje řešení, kterým je nadstandardní funkce node-set" mě opravdu dostala. Řekl bych, že standardy jsou tu právě od toho, aby se dodržovali. Pokud mají nějaké nedostatky, tak se poměrně vyvíjejí. Použitím této funkce si zavřu cestu pro použití jiných parserů. což mi nepřijde jako moudré řešení.
Funkce může asi být užitečná, ale dá se vyřešit i jinak. Proč se mají standardy držet je snad jasné, když se podíváme na rodlíly v HTML a CSS pro jednotlibé browsery.
Datum vložení: 8.7.2004 10:14:40
V podstatě máte pravdu. Ale pokud už vyvíjíte na M$ platformě, stejně přenositelnost XSLT na 99,9% nevyužijete. V HTML má puntičkářské dodržování standardů samozřejmě mnohem větší smysl. Také nezapomeňte, že XSLT je samo o sobě pouze částí nějaké aplikace, a zbytek je obvykle opět platformově závislý (stále mluvíme o M$ platformě). A dalším faktem je, že toto M$ rozšíření využívá standardní mechanismus XSLT extenzí, který v XSLT specifikaci určitě najdete, klidně se podívejte.
Datum vložení: 8.7.2004 13:49:00
Nemyslim si, ze proto, ze vyvojim neco na MS, tak se musim drzet jen nastroju MS. XSLT pouzivame hlavne na MS, ale samotna transformace je v jave. Pokud se budeme drzet specifikace, tak pak neni problem pro nejakeho jineho zakaznika zmenit XSLT na neco jineho, treba ten od MS. Ve Vami doporucovanem pripade by jste se pak dostal do problemu a musel se venovat uprave stareho kodu, coz asi neni cileny stav.
Datum vložení: 8.7.2004 14:08:49
Nenapadá mě žádný důvod takto střídat XSLT procesory, navíc v aplikaci na MS používat javovský? Proč? No budiž. Nicméně vypadá že máte s XLST zkušenosti, takže určitě víte že XSLT samo o sobě nabízí základní funkčnosti, ale v reálu jí potřebujeme mnohem více. V podstatě máme tři možnosti: potřebnou funkčnost implementovat jako úpravu vstupního dokumentu, nebo výstupního dokumentu, a nebo jako XSLT extenzi. Ve všech třech případech je tato funkčnost řešena mimo XSLT, je tedy platformově závislá. Ať již pod pojmem platforma míníme procesor, a nebo programové prostředí (Java, .NET). A uvedená funkce ms:node-set je prostě jen příkladem XSLT extenze, kterou implementuje přímo procesor. Takže vůbec nejde o nějakou zběsilost. A když už to tak rozpitváváme, IMHO tuto funčnost nebude problém doprogramovat jako extenzi k jakémukoli procesoru, který extenze podporuje. A také ji umístit do shodného jmenného prostoru... a opět jsme dosáhli 100% kompatibility .-) Jsem přesvědčen o "své pravdě", protože u nás je tato funkce pro náš projekt (CMS) velmi užitečná, využití jiného procesoru by u nás nemělo žádný smysl. Proč by nemohla být stejná situace i někde jinde? Doporučuji nehádat se se mnou, jsem velmi tvrdohlavý :-))) Ale i tak díky za příspěvky, těším se na další reakci :-)
Datum vložení: 8.7.2004 15:07:12
Rozhodně se nechci hádat, neboť zase tak kovanej v XSLT nejsem, už jsem je dlouho nepoužíval. Ale nastíním naše řešení. Máme aplikační server napsaný v Jave. Tam vygenerujeme XML, na které máme připravené šablony pro tvorbu HTML výstupu.
Takže samotná transforamce je vykonána v Jave, tudíž není problém si na to vzít jakoukoliv knihovnu. Myslím tedy zřejmě kromě MS verze, ta asi v Jave nebude.
A teď proč chceme změnit v průběhu práce XSLT procesor a použít jiný? Prostě proto, že se takový nabízí a má jiné výhody, například je rychlejší. Tento konkretní problém jsme už řešili.
Samozřejmě máte pravdu, asi tak jak jsem psal na začátku já, že si lze pomoci jinak a docílit kýženého stavu. To je samozřejmě pravda. Já jsem však chtěl upozornit jen na fakt, že Vaše tvrzení není (alepoň pro mě) "to pravé ořechové". To že MS udělá nějaké rozšíření nad standard není podle mě výhoda, ale spíše nevýhoda. Pak to svádí k tomu to používat a tím se zavírají cesty pro rozšíření či změnu, tak jak bylo pospané výše.
Smutnou pravdou je, že nebýt těchto rozšíření, tak se asi specifikace moc nehýbou. Ale v článku bych takovéto obraty nepoužíval, neboť jsou zavídějící a nezkušeného čitatele mohou uvést na zcestí :-))).
Datum vložení: 8.7.2004 15:21:51
Myslím že z věty, kterou jsem použil, je jasné, že toto řešení se omezuje pouze na M$ procesory, takže to nijak zavádějící není. Pokud se vám XSLT extenze nelíbí, můžete klidně nadávat i na jiné procesory, protože ty mají také své vlastní - to nevím z vlastních zkušeností, ale od Koska ;-) Kdybych je znal, psal bych také o nich. I když každá z nich zabraňuje přenositelnosti. Ale podle mě to opravdu není žádné velké zlo, protože XSLT je jen část aplikace, a zbytek přenositelný stejně není. A XSLT málokdy tvoří většinu aplikační logiky, takže 100% přenositelnost není žádná velká výhra. Ale to už bych se opakoval :-) Takže AVE XSLT, a nechť si každý udělá názor svůj, neboť absolutní pravda neexistuje ;-)
Datum vložení: 8.7.2004 15:47:35
Sice jsem uz odpovidat nechtel, ale prece jen si neodpustim jednu poznamku.
Ja nepremyslim o XSLT extenzich jako o zlu, i kdyz je nemam v oblibe. Je to proste dalsi moznost, pokud vim, co delam. Jak pisete Vy, vystacite si jen s MS procesorem.
Me se jen nelibila pouzita veta. Potrebuji nejakou funkcnost na kterou nebylo pamatovano ve standardu, ale zaplat panbuh ji nabizi "tento procesor". At by to byly treba i jine extenze jinych procesoru.
Asi se nema cenu dale prit, nebot kazdy mame svoji pravdu nekde trochu jinde. Ale svazovat se takto s jednim produktem mi neprijde jako stastne. Vysvetloval jsem to jiz predtim, napriklad z duvodu rychlosti, je nekdy nezbytne sahnout po produktu jinem.
Howgh, domluvil jsem ...