[php] Template engine vs. XML + XSLT

[Rense Klinkenberg]

Je hoort iedereen hier altijd juichen over template engine's en mensen die trots zijn op hun eigen engine, maar waarom zou je een template engine gebruiken, als je met PHP veel meer kan?

Ik heb een tijd geleden kennis gemaakt met de XSLT functies van PHP.

Voor degene die XSLT niet kennen: XSLT is een opmaaktaal transformatietaal voor XML data. Hierdoor kan je XML data omzetten naar een mooie HTML pagina, met alles erop en eraan.

Sinsdien gebruik ik geen template engines meer, maar laat ik m'n scripts XML genereren, die daarna door de XSLT parser van PHP wordt omgezet naar mooi HTML.

Wat ik me nu eigenlijk afvroeg is of ik een van de weinige ben die dit doet, of dat er al meer mensen zijn?

edit: Zie correctie van de post hieronder

[didio]

Is misschien helemaal nog niet zo'n gek idee, ik heb nu ook mijn eigen template engine, wel in ASP geschreven dan.

Heb wel eens wat gedaan met xml/xslt misschien moet ik er eens wat dieper op in gaan.

[mbravenboer]

freak007: Voor degene die XSLT niet kennen: XSLT is een opmaaktaal voor XML data. Hierdoor kan je XML data omzetten naar een mooie HTML pagina, met alles erop en eraan.

Je bedoelt het vast goed, maar ik moet het toch corrigeren . XSLT is een transformatie taal voor XML. Je kan een XML document naar elk willekeurig formaat transformeren (XHTML, HTML, WML, XML, Latex, plain-text, RTF enzovoorts). Het is dan ook absoluut geen opmaaktaal.

Sinsdien gebruik ik geen template engines meer, maar laat ik m'n scripts XML genereren, die daarna door de XSLT parser van PHP wordt omgezet naar mooi HTML.

Zeer interessante mening en iets waar ik inderdaad ook al tijden voor ben . Bovendien blijken transformaties dermate snel te gaan, dat performance geen probleem mag zijn.

Ik denk dat het gebruik van XSLT/XML ipv templates vooral voordelen heeft met betrekking tot de aangeboden data. Bij de eerste oplossing (XSLT) biedt je je data namelijk automatisch ook in XML vorm aan. Bij de tweede, moet je daar wat moeite voor doen.

Wat ik me nu eigenlijk afvroeg is of ik een van de weinige ben die dit doet, of dat er al meer mensen zijn?

Ik gebruik wel XSLT (onder andere voor een posting taal waar ik nu aan werk). Ook gebruik ik het voor veel andere toepassingen, die niet direct met het web te maken hebben. Ik denk dat de browser support voor XSL in IE 6 en Mozilla jouw oplossing een stuk interessanter maken dan templates.

[brammetje]

hmmz.. het is zeker interessant, maar ik heb er nog nooit mee gewerkt..

heb je misschien een leuk voorbeeldje te showen??

[dusty]

Een template engine kan natuurlijk ook XML als invoer van de gegevens krijgen he

[Rense Klinkenberg]

PlayR:heb je misschien een leuk voorbeeldje te showen??

http://www.xmlpitstop.com/Examples/WebWorkShop/Multiple_views/multiple.htm laat zien hoe je met verschillende XSLT's een compleet andere lay-out hebt.

[oh,when?]

Op dinsdag 28 augustus 2001 13:51 schreef freak007 het volgende:
Sinsdien gebruik ik geen template engines meer, maar laat ik m'n scripts XML genereren, die daarna door de XSLT parser van PHP wordt omgezet naar mooi HTML.

Wat ik me nu eigenlijk afvroeg is of ik een van de weinige ben die dit doet, of dat er al meer mensen zijn?

zo..om toch nog ff oude koeien uit de sloot te halen (vond via een andere thread deze link) nog ff mijn 2 centjes toe te voegen..

Ik kan me nog hele lange discussies herinneren over de stelling dat PHP zelf een template parser is, en waarom het dan zo onlogisch is om hier weer een template parsers voor te schrijven. Dat lijkt totaal onlogisch, en dat is het in principe ook. Juist de XSLT standaard is gemaakt om data te transformeren naar een ander formaat, of dat nu een XML file is of voor een representatief formaat is, zoals HTML.
Ikzelf heb ook na zitten te denken over de transformatie:

DATA -> XML(mbv PHP) -> XSLT (icm PHP ) -> XHTML/WAP/PDA etc..

ten opzichte van:

DATA -> PHP -> Template engine(noem ze maar op) -> XHTML

Dit is in principe een hele handige oplossing, maar:

De meeste projecten waar je meestal aan werkt ( 90% van mijn huidige projecten ) , zijn vaak alleen nog voor voor het web, en zullen zelden of nooit voor een ander media gebruikt worden ( ik denk aan Wap, of PDA Light Version, Flash, etc..) (helaas )

Als ik dat al vantevoren weet, is het naar mijn inziens overkill om dan eerst XML te genereren, om daarna via XSL transformaties een XHTML output te krijgen, terwijl dit ook in PHP zelf kan (al dan niet in combinatie met een zelfgeschreven template parser). Dit vanwege de volgende redenen:


• Hoe je het ook wend of keert, het is een extra stap die je zal moeten maken, dus extra (onnodige) overhead.
• Inherent daaraan is vaak de combinatie zonder XML stappen sneller dan de stap met XML.
• De meese junior programmeurs (die vaak op dit soort klussen worden gezet ) hebben vaak weinig tot geen ervaring met XML/XSLT, danwel wel veel ervaring met hun template-parsers. Vaak zullen ze dan sneller iets maken met iets waar ze vertrouwd mee zijn. (zwak argument, ik weet het..)
• De meeste webdesigners, kunnen redelijk hun XHTML templates maken, die dan worden afgeleverd aan het webdevelopment team. Echter ik zie de meeste van hen niet zo snel een XSL Stylesheet maken, dit om de simpele reden dat zij vaak visueel ingestelde mensen zijn. Mijn mening is dat het schrijven van een XSL Stylesheet toch weer een stapje verder is dan XHTML.

Kortom, als een project bij ons alleen, en alleen voor het web is, en er geen data hoeft worden uitgewisseld, en geen meerdere formaten hoeven worden gemaakt, dan zal er bij ons vaak de combinatie PHP + Template parser gebruikt worden, dan dat er een XML / XSLT / PHP gemaakt gaat worden.

Echter ik ben wel van mening dat het een onlogische stap ( eigen template parser in PHP ) is, terwijl er juist standaarden voor zijn.

just my IMO

[mbravenboer]

oh,when?: zo..om toch nog ff oude koeien uit de sloot te halen (vond via een andere thread deze link) nog ff mijn 2 centjes toe te voegen..

Linkjes strooien heeft dus zin . Leuk stukje! Mijn reactie...

De meeste projecten waar je meestal aan werkt ( 90% van mijn huidige projecten ) , zijn vaak alleen nog voor voor het web, en zullen zelden of nooit voor een ander media gebruikt worden ( ik denk aan Wap, of PDA Light Version, Flash, etc..) (helaas )

Dat is inderdaad wel een goed argument. Het is in feite ook zo dat XML+XSLT pas echt een killer oplossing wordt als je meerdere views op dezelfde data wilt hebben.

Maar... een website kan erg veel winnen bij een opzet in twee gescheiden lagen. In de huidige situatie wordt de 'view' vaak gegeneerd uit een vastgelegd deel van de data. Per pagina wordt er een template aangemaakt en deze wordt ingevuld met een bepaalde data-set. Als de presentatie zo aangepast wordt dat er meer data nodig is, ben je de lul. De code moet aangepast worden om die extra data ook aan te leveren. De template wordt immers 'ingevuld'.

Bij een XML-XSL oplossing heb je op dit punt een belangrijke voorsprong. Allereerst is je presentatie nog veel onafhankelijker van de data. De presentatie kan namelijk ook zelf andere data erbij betrekken om zo nieuwe combinaties te maken.

Het is voor de onderhoudbaarheid en duidelijkheid erg handig om een je site niet op te zetten als een verzameling HTML files. Bij templates zie je veel dat er een 1 op 1 mapping is van data-producers naar HTML pagina's. Bij XML-XSL hoeft dat helemaal niet het geval te zijn.

Het mooi van de XML-XSL oplossing is dat je je namelijk allereerst gaat verdiepen in de data die je te bieden hebt. Deze biedt je aan in XML vorm. Je maakt je daarbij absoluut niet druk om de presentatie en welke zeker niet om de data die een presentatie nodig zou kunnen hebben. Daarna kan je met behulp van XSLT data-bronnen gaan transformeren naar XHTML. Je kan daarbij heel gemakkelijk bronnen combineren.

Voordeel: je bent bij het produceren van data 'atomair' bezig. Je maakt je niet druk om het combineren van gegevens.

Ik moet uiteraard wel toegeven dat het een complicerende factor is. Ik denk ook niet dat webdesigners XSL stylesheets zouden moeten gaan schrijven. De opzet van een duidelijke scheiding tussen de data die je aanbiedt en de presentatie op het web zorgt echter wel voor een enorme professionalisering die zeker de moeite waard zal blijken te zijn op de lange termijn.

Nog even over de discussie of PHP nog wel een template parser nodig heeft: deze discussie ontstaat in feite omdat je een scheiding wilt maken tussen het construeren en combineren van data en het vertalen naar een presentatie. Dat zou je niet in 1 mengsel willen doen. Als je dan een scheiding aanbrengt is het denk ik beter om de data-laag ook echt te scheiden van de presentie dus niet:

code:

HTML <- Data opbouw  in  <- Databron X
            ||
            \/           
          Template

Maar:

code:

HTML <- Transformatie <- Data opbouw  in PHP <- Databron X

Inherent daaraan is vaak de combinatie zonder XML stappen sneller dan de stap met XML.

Als je direct in PHP HTML genereerd denk ik dat je inderdaad gelijk hebt. Als je echter XML genereerd moet je het voordeel van standaard tools niet onderschatten. Omdat XML een standaard is, kan er flink geinvesteerd worden in XSL engine. De performance van Xalan vind ik bijvoorbeeld al buitengewoon goed.

De meese junior programmeurs (die vaak op dit soort klussen worden gezet ) hebben vaak weinig tot geen ervaring met XML/XSLT, danwel wel veel ervaring met hun template-parsers. Vaak zullen ze dan sneller iets maken met iets waar ze vertrouwd mee zijn. (zwak argument, ik weet het..)

Das dus een missie voor ons .

Mijn mening is dat het schrijven van een XSL Stylesheet toch weer een stapje verder is dan XHTML.

Inderdaad, maar misschien moet het web ook weleens een stapje verder. Persoonlijk denk ik dat al het gepruts op het web een enorme belemmering van de technologische vooruitgang is. Baggere HTML, slechte opgezette, niet modulaire systemen zorgen voor een chaos. Eigenlijk zou ik het liefst gecompileerde (gevalideerde dus) XHTML willen zien als enig geaccepteerde content in een browser.

[brammetje]

Ondertussen ben ook ik in aanraking gekomen met XML en XSLT, uit mijn ondertitel mag je wel opmaken dat ik het een goede oplossing vind voor het scheiden van data en opmaak

De enige reden waarom ik het niet veel gebruik is het gebrek aan hosting. Mijn 'werkstukjes' gaan vaak naar veel verschillende hosters. Op het moment is de ondersteuning voor serverside transformatie gewoon nog zo sporadisch te vinden dat je altijd weer moet bedelen bij je hoster om een of andere module of app te installeren. Client-side transformatie is natuurlijk nog helemaal niet aan de orde..

Verder ben ik wel met je eens dat het zich minder leent voor kleinere projecten, maar ik denk ook niet dat het daar echt voor bedoelt is. Toch zie je bij gemiddeld grote projecten al snel dat je van een bepaalde pagina een printversie ofzo wilt hebben, en een simple xsl-file kan daar uiteraard heel goed voor zorgen

Buiten scheiding van data en presentatie is een ander voordeel van XML dat het cachen vrij gemakkelijk maakt. Je slaat gewoon ergens een xml filetje op. Dat is kleiner dan een html-file, en bij verandering van de lay-out hoef je niet meteen als je files opnieuw te genereren..
* brammetje XML/XSLT spammer groet u

[Orphix]

Ik ben er ook mee bezig geweest, en aangezien ik altijd een vrij simpele (zelfgemaakte) template engine had gemaakt ben ik er zeer tevreden mee. Een ander voordeel wat ik nog niet heb gelezen dat ik er in geloof dat dit een goed ondersteunde standaard gaat worden. Dit betekent dat iemand anders jouw templates erg gemakkelijk kan aanpassen zonder dat die jouw eigen template-engine-syntax moet aanleren. Bovendien merk ik in mijn projectjes dat het enorm helpt om modulair en zelfs abstract te kunnen programmeren.
Een punt wat me toch wel een beetje dwarszit is dat je intern een enorme XML bestand opbouwt, die door de tags veel groter is dan de pure data terwijl je er verder niks mee doet... Maarja dat is de trade-off tussen snelheid en gemak. En ik kies voor het laatste.

[mbravenboer]

Orphix: Een punt wat me toch wel een beetje dwarszit is dat je intern een enorme XML bestand opbouwt, die door de tags veel groter is dan de pure data terwijl je er verder niks mee doet...

Daar staat weer tegenover de HTML in veel gevallen nog groter zou zijn....

[Rense Klinkenberg]

Op zaterdag 17 november 2001 16:21 schreef oh,when? het volgende:<li> Hoe je het ook wend of keert, het is een extra stap die je zal moeten maken, dus extra (onnodige) overhead.

Maar je kan je script wel veel generieker en abstracter programmeren, waardoor je efficientere scripts kan maken. Verder kost het makan van de scripts ook minder tijd.

• Inherent daaraan is vaak de combinatie zonder XML stappen sneller dan de stap met XML.

Zoals mbravenboer al zie, zijn xslt parser gespecialiseerd in hun snelheid. Ik ben zelf ook erg goed te spreken over de snelheid van de parser die bij php zit: Sabletron.</li>
Wat ook niet vergeten moet worden is dat de meeste template engines vaak met erg ranzige regexen werken en daardoor soms best langzaam kunnen worden.

Kortom, als een project bij ons alleen, en alleen voor het web is, en er geen data hoeft worden uitgewisseld, en geen meerdere formaten hoeven worden gemaakt, dan zal er bij ons vaak de combinatie PHP + Template parser gebruikt worden, dan dat er een XML / XSLT / PHP gemaakt gaat worden.

Dat kan je natuurlijk ook omdraaien: Zolang iedereen stug bij hun template engine blijft, zal het moeilijk voor ze blijven om meer output vormen dan (x)HTML te leveren.
Ik gebruik xml/xslt niet omdat het zo simpel is (ja, eigenlijk ook wel), maar omdat ik dan later met dezelfde code ook hele andere dingen kan doen.

[Rense Klinkenberg]

Op zaterdag 17 november 2001 17:09 schreef mbravenboer het volgende:Als de presentatie zo aangepast wordt dat er meer data nodig is, ben je de lul. De code moet aangepast worden om die extra data ook aan te leveren. De template wordt immers 'ingevuld'.

Wanneer je met xml/xslt werkt moet je ook je xsl nog aanpassen en als je pech heb ook wat extra regeltjes code (afhankelijk van hoe generiek de scripts zijn).

[mbravenboer]

freak007: Wanneer je met xml/xslt werkt moet je ook je xsl nog aanpassen

Uiteraard, XSL zorgt immers voor de presentatie... Je past dus in feite de presentatie aan.

en als je pech heb ook wat extra regeltjes code (afhankelijk van hoe generiek de scripts zijn).

Mwah, als je al de beschikbare data beschikbaar stelt als XML hoe je nooit meer code te schrijven als je presentatie andere data wil weergeven... bij templates moet je die extra data dan gaan invullen... Als je niet al je data beschikbaar hebt gesteld, moet je inderdaad aan het proggen .

[Johannes]

Op zaterdag 17 november 2001 23:05 schreef mbravenboer het volgende:
Mwah, als je al de beschikbare data beschikbaar stelt als XML hoe je nooit meer code te schrijven als je presentatie andere data wil weergeven... bij templates moet je die extra data dan gaan invullen... Als je niet al je data beschikbaar hebt gesteld, moet je inderdaad aan het proggen .

Sjah, maar als je een heel erg snel veranderende site/forum hebt, dan kun je echt niet bij elke update weer je hele XML gaan genereren, je moet dan toch echt voor verschillende pagina's verschillende delen van je XML naar de output dumpen. Ook werkt dit volgens mij niet helemaal lekker met auth systemen, want je moet dan elke keer alle XML er uit filteren die de client niet mag zien. Dit geldt natuurlijk alleen voor client-side parsing, maar ja, je wilt toch ook niet dat je voor eeuwig met server-side parsing opgescheept zit.

[HenkS]

Op dinsdag 28 augustus 2001 14:36 schreef freak007 het volgende:
PlayR:heb je misschien een leuk voorbeeldje te showen??

http://www.xmlpitstop.com/Examples/WebWorkShop/Multiple_views/multiple.htm laat zien hoe je met verschillende XSLT's een compleet andere lay-out hebt.

en toch raak ik niet overtuigd over dit alles, wanneer wil je zoiets nu, bedoel maar: je hebt een site met een layout als je iets anders wilt, dan pas ik mijn template files ook snel aan, of mijn stylesheet, wanneer wil je nu verschillende layouts van 1 ding? zie het voordeel niet, en volgens mij is de produktie tijd met dit toch ook langer? of zie ik dat nu echt helemaal verkeerd?

[Rense Klinkenberg]

Op maandag 19 november 2001 09:53 schreef HenkS het volgende:... wanneer wil je nu verschillende layouts van 1 ding? zie het voordeel niet, en volgens mij is de produktie tijd met dit toch ook langer? of zie ik dat nu echt helemaal verkeerd?

Vaker dan je je waarschijnlijk bewust bent.
Ik doe mee aan een boeken bestel systeem. Daarmee wordt op verschillende pagina's een boek gerepresenteerd. Omdat je met xslt daar gewoon 1 template van kan maken, hoef je niet vor elke pagina hetzelfde stuk te copy/pasten uit de andere templates.
En als we een boek anders willen representeren, hoeven we alleen 1 template blokje aan te passen en klaar.

In een forum zijn bijvorbeeld ook veel stukken te vinden waar je aparte xsl:template blokjes van kan maken.

Met xml/xsl kan je alles veel generieker aanpakken, zodat je ook niet per aparte pagina die afgebeeld wordt een aparte template pagina hoeft te maken. Je kan gewoon 1 grote xsl maken, waarin je aangeeft hoe verschillende onderdelen gerepresenteerd moeten worden. Als je dat eenmaal een beetje door hebt, kan het je best een hele hoop werk schelen met het opbouwen van je templates.

[HenkS]

maar als ik het dus goed zie:

kan ik het beste templates gebruiken als ik html/php gescheiden wil houden en er zeker van ben, dat ik de data maar op 1 manier hoef te presenteren (dus waarschijnlijk de kleinere sites)

en ga ik xml+xslt+php gebruiken als data op meerdere manieren gepresenteerd moet gaan worden, zoals dus jouw boeken site, of bv als users bv een site bezoeken met verschillende login niveaus en betrekkende op het niveau ieder hun eigen 'layout' krijgen, dan heeft het wel nut?

want in mijn 1e geval, dus als je maar op 1 manier hoeft te presenteren, lijkt mij xml+xslt teveel produktie tijd vereisen?

[brammetje]

ik denk dat XML en XSLT niet zo bar veel langer duren om te ontwikkelen dan een oplossing met templates hoor.. Verder is het onderhoud ook een stuk makkelijker.

Wat natuurlijk ook nog mee speelt is de snelheid van je eind-product, en dat ligt met xml denk ik hoger.

Zoals ik eerder al zei zijn de oplossingen voor serverside parsing bij maar weinig hosters aanwezig

Al met al, XSLT rockt

[Rense Klinkenberg]

Een ander voordeel van xml, is dat je content heel makkelijk als xml kan aanbieden. Hierdoor zijn "turbotrackers" erg makkelijk te maken.

[oh,when?]

Op zaterdag 17 november 2001 22:41 schreef freak007 het volgende:

[..]

Maar je kan je script wel veel generieker en abstracter programmeren, waardoor je efficientere scripts kan maken. Verder kost het makan van de scripts ook minder tijd.
[..]

Hoe kunnen mijn scripts veel abstracter zijn, en waarom zijn ze efficienter? Nogmaals, als ik simpelweg een eenvoudig xhtml output verlang van een junior programmeur, en hij komt met hele xslt/xml constructies aanzetten dan is dat gewoon overkill.

Zoals mbravenboer al zie, zijn xslt parser gespecialiseerd in hun snelheid. Ik ben zelf ook erg goed te spreken over de snelheid van de parser die bij php zit: Sabletron.</li>
Wat ook niet vergeten moet worden is dat de meeste template engines vaak met erg ranzige regexen werken en daardoor soms best langzaam kunnen worden.

De meeste template engines zijn idd erg ranzig gecode, maar sommige zijn zeker efficient te noemen. Ik heb helaas geen benchmarks van het snelheid/load op server verhouding ( XML+PHP vs Template+PHP ). Misschien iets om een keer te doen

Dat kan je natuurlijk ook omdraaien: Zolang iedereen stug bij hun template engine blijft, zal het moeilijk voor ze blijven om meer output vormen dan (x)HTML te leveren.
Ik gebruik xml/xslt niet omdat het zo simpel is (ja, eigenlijk ook wel), maar omdat ik dan later met dezelfde code ook hele andere dingen kan doen.

Nogmaals, voor een simpel XHTML site, die nooit en te nimmer voor data syndication gebruikt zal worden, en waar snel ff een webdesigner en beginnend php programmeur opgezet word, is XSL/XML gewoon overkill.

Ook al zijn er mooiere oplossingen, in de praktijk werkt het vaak net iets anders...

[tomato]

oh,when?: Nogmaals, voor een simpel XHTML site, die nooit en te nimmer voor data syndication gebruikt zal worden, en waar snel ff een webdesigner en beginnend php programmeur opgezet word, is XSL/XML gewoon overkill.

Toch ben ik dit niet met je eens. Zeker wanneer de grafisch ontwerper een beetje om kan gaan met XSL of alleen maar doorheeft hoe het werkt en wat de mogelijkheden (en onmogelijkheden) zijn kan dat grote voordelen bieden!

[Verwijderd]

ff een vraagje...

XML samen met XSLt is een wereldcombinatie, heb hier tijdens mijn stage (waar ik overigens nog steeds mee bezig ben) mee kennisgemaakt... Voor de rest ben ik fervent php-gebruiker. Met template engine die ergens op het internet rondslingerde (zonder reg-exen overigens). De combinatie ken ik echter nog niet.

Nu werk ik met php veel met database achter de webpagina voor de content. Dit performt goed.

Mijn vraag: bij gebruik van XSL(t) heb je dan perse XML input nodig, of kan die input ook uit je database komen? Dan zie ik een groot voordeel boven op de template engine die ik normaal gebruik

[brammetje]

Op dinsdag 20 november 2001 19:32 schreef Grofur het volgende:
Mijn vraag: bij gebruik van XSL(t) heb je dan perse XML input nodig, of kan die input ook uit je database komen? Dan zie ik een groot voordeel boven op de template engine die ik normaal gebruik

jep, xml is wel nodig voor xslt ja

[mbravenboer]

Grofur: Mijn vraag: bij gebruik van XSL(t) heb je dan perse XML input nodig, of kan die input ook uit je database komen? Dan zie ik een groot voordeel boven op de template engine die ik normaal gebruik

Het gebruik van XML is inderdaad noodzakelijk. Wat je wel kan doen is een generieke methode maken om resultaten van database-queries naar XML om te zetten. Dit wordt dan niet echt mooie XML code, maar daar kan je dan weer een transformatie overheen halen. Hier op GoT is deze methode weleens besproken:

[topic=289975/1/25]

[mbravenboer]

Hum toch maar niet

[oh,when?]

Op maandag 19 november 2001 23:45 schreef tomato het volgende:

[..]

Toch ben ik dit niet met je eens. Zeker wanneer de grafisch ontwerper een beetje om kan gaan met XSL of alleen maar doorheeft hoe het werkt en wat de mogelijkheden (en onmogelijkheden) zijn kan dat grote voordelen bieden!

Ging het maar zo makkelijk:

- Ik: "Hier heb je een boek over XSL, ga maar eens lezen.."
- Webdesigner: "XSL? wat moet ik daarmee dan?"
- Ik: "Nou, we gaan langzaam overstappen op XML+XSLT"
- Webdesigner: "Maar waarom moet ik dan XSL leren??"
- Ik: "Omdat we het nodig vinden dat iedereen kennis heeft van XSL"
- Webdesigner: "Alweer iets nieuws? Ik ben al druk bezig met XHTML, DOM Javascript, CSS, etc etc.."
- Ik: "tja.."

mensen zijn geen machines...je kunt helaas geen chip of module implementeren waardoor je opeens nieuwe kennis bezit. Het invoeren van XML in je organisatie vereist tijd en kennis van je medewerkers, tijd die zowiezo schaars is. In onze organisatie zijn we vollop aan het orienteren naar wat er mogelijk is, en wat er nuttig is voor ons en daartoe behoort zeker wel het hele XML gebeuren. Echter de meeste kennis ligt nu nog steeds bij template engines. Ik schat dat 80-90 procent van de huidige kennis in de bedrijven meer daarop is gericht. goede XSLT programmeurs zijn nog schaars, en voor veel organisaties zeker onbetaalbaar. De komende 12-18 maanden zullen op dit gebied dan ook belangrijk worden.



ps: Wat ook een leuke discussie is om te lezen:

XSP vs PHP

I would concur that PHP is easier to setup than XSP. Lots of reasons: It's
more mature, has a simpler processing model, has more users, and is not a
part of a larger architecture (AxKit in this case).

But PHP is a bit different to XSP. Quite a bit. PHP operates under the old
"page processing" model. So you have commands on a page that send output
to a browser. And it's all strings. You can do lots and lots of things
with PHP - it has in-built support for all sorts of goodies like email,
databases, imap, ldap, etc. But all that stuff seems to be using
functional interfaces (so you do things like mysql_connect(), rather than
an OO interface). Basically, your pages end up with lots of code on them.
This is easy for a beginner, but more complex to scale up (although lots
of projects have managed it, it seems).

[tomato]

oh,when?: Ging het maar zo makkelijk: [..]

Goed punt. Gisteren heb ik het er toevallig op mijn werk ook nog over gehad naar aanleiding van een functioneel ontwerp waar ik mee bezig was.
De code klopper wil eigenlijk het liefst niets met XSL te maken hebben, of hooguit de applicatie ontwikkelen met een voorbeeld of standaard stylesheet en het verder over laten aan de verantwoordelijken voor de layout.
Maar XSL is een transformatietaal en daarmee programmeer je gewoon, dat is een ver van mijn bed show voor de grafisch ontwerper. Zowiezo is nauwe samenwerking een vereiste (maar dat was het altijd al), maar uiteindelijk zal toch iemand die stylesheets moeten implementeren. Nou is het misschien niet zo'n ramp als de programmeur dit moet doen, als de ontwerper maar goed weet wat de (on)mogelijkheden van XSL zijn, zodat hij daar rekening mee kan houden.

Het is altijd al lastig, ook als je niet met XML/XSL werkt. Layout moet soms ook geprogrammeerd worden (denk aan JavaScriptjes, geavanceerdere Flash, etc). Daarom vind ik dat het eigenlijk noodzakelijk is dat de grafisch ontwerper enige kennis van de technieken heeft (zelf implementeren bedoel ik dus niet), om een goede wisselwerking te kunnen krijgen.

Je kunt stellen dat dit voor grotere projecten makkelijker wordt, omdat er dan meer ruimte is voor gespecialiseerde ontwikkelaars en niet iedereen een homo universales hoeft te zijn. Dit laatste verwacht ik overigens wel van een projectleider of een functioneel ontwerper, ik zie in de praktijk helaas vaak het tegendeel (gevolg is slecht projectmanagement).

[zeroxcool]

Even stupid doen... Maar wat is nou precies XML? Ik hoor op GoT er vanalles over, waar kan ik tut's vinden. Ik loop echt achter met m'n tijdklokje hoor .

[mbravenboer]

In dit topic staan een aantal links naar goede inleidende XML/XSL topics op GoT. Daarin staat aardig wat uitleg wat XML is, wat XSL(T) is en er staan ook wel links naar tutorials . Zie ook de FAQ van Programming.

[topic=219528/1/25]

[Orphix]

Nog even over dat leerproces. Veel huidige template engines werken met simpele substitutie methoden. Als een bedrijf slechts die functies gebruikt is XSLT heel makkelijk aan te leren, in feite heb je dan alleen een <xsl:template match="..."> en <xsl:value-of select="..."> nodig. Je hoeft slechts een paar elementen te kennen om een krachtige template te maken.
Als er later meer geavanceerde dingen in moeten komen. Kan dat worden gedaan door de programmeur of door de vormgever die inmiddels zo verslaafd is geraakt aan XSLT dat die de syntax zo uitpoept

[brammetje]

Op zaterdag 24 november 2001 15:56 schreef Orphix het volgende:
Nog even over dat leerproces. Veel huidige template engines werken met simpele substitutie methoden. Als een bedrijf slechts die functies gebruikt is XSLT heel makkelijk aan te leren, in feite heb je dan alleen een <xsl:template match="..."> en <xsl:value-of select="..."> nodig. Je hoeft slechts een paar elementen te kennen om een krachtige template te maken.
Als er later meer geavanceerde dingen in moeten komen. Kan dat worden gedaan door de programmeur of door de vormgever die inmiddels zo verslaafd is geraakt aan XSLT dat die de syntax zo uitpoept

Klopt, dit dacht ik eigenlijk ook.. Toch zal het voor mensen die alleen html kunnen even anders denken zijn, en sommige mensen vinden dat erg moeilijk (krijg je met die artistieke types )..

Verder zou je met XSL idd gewoon een soort templates kunnen maken zoals je dat bij andere dingen ook doet. een beetje value-of select, en for-each select dingen, maar je krijgt dan wel lelijke XSL Templates (in de zin van template-match) is juist de sterke kant van XSL, en dat is juist weer een hele andere gedachtengang... Jammer maar helaas, dat leer je sommige mensen niet zomaar..

[mbravenboer]

PlayR: een beetje value-of select, en for-each select dingen, maar je krijgt dan wel lelijke XSL Templates (in de zin van template-match) is juist de sterke kant van XSL, en dat is juist weer een hele andere gedachtengang... Jammer maar helaas, dat leer je sommige mensen niet zomaar..

Ruik ik hier een converter? .

In principe is uit:

1. een template incombinatie met
2. een DTD van een XML-bron
3. en eventueel nog een binding van die xml-bron naar variabelen in de template vertaald

waarschijnlijk vrij gemakkelijk een XSL stylesheet te genereren. Deze zal dan waarschijnlijk vrij lelijk zijn, maar ik denk dat je ook wel behoorlijk wat herschrijf-regels kunt opstellen om dat dan weer te gaan herschrijven naar een mooiere XSL stylesheet .
Maar goed, ff serieus... als je XSLT op een simpele manier gebruikt is de omslag van templates naar XSLT helemaal niet ingewikkeld. Later kan je dan nog de extra uitdrukkingskracht van XSLT gaan benutten.

[brammetje]

Op zaterdag 24 november 2001 16:50 schreef mbravenboer het volgende:
Ruik ik hier een converter? .

hmmz

een template op een template toepassen, kinky hoor

werkt dat wel, nog nooit geprobeert eigenlijk

[mbravenboer]

PlayR: een template op een template toepassen, kinky hoor

Tja, het geinige van XSL is dat je het ook kunt toepassen op XSL . Je kan dus gewoon een stylesheet transformeren met een stylesheet (volgens mij had ik zoiets een tijdje geleden als uitdaging ergens aangegeven ).

Bij een template wordt dat natuurlijk wat lastiger: je moet de template gaan parsen, naar XML omzetten en daarna transformeren.

Bovendien is er wel een kans dat XSLT niet de ultieme taal is om een dergelijke vrij complexe tranformatie van template naar stylesheet te implementeren. Als het te complex wordt moet je toch naar een echte transformatie-taal overstappen (Stratego bijvoorbeeld...).

werkt dat wel, nog nooit geprobeert eigenlijk

Alles werkt. Alles transformeert .