Frames in xml eigenlijk in een xsl...

[Verwijderd]

Hoe maakt men een frame zoals men die met html maakt, maar dan met xml in een xsl?

[Verwijderd]

Met een XSL kun je de data uit de XML in een XHTML bestand gieten. Maar ik denk dat je zelf toch echt even moet gaan kijken hoe het precies werkt, want volgens mij kun je gewoon je frameset in HTML maken.

[Orphix]

Je maakt dus een frames.html die verwijst naar bv 3 andere pagina's (3 frames).
Je _kan_ wel met XML+XSL een frames-index pagina maken maar dit is een beetje onzinnig aangezien de data
a)enorm klein is en
b)praktisch nooit verandert

[oh,when?]

Op dinsdag 08 januari 2002 21:49 schreef Orphix het volgende:
...aangezien de data...
b)praktisch nooit verandert

XML en data die vaak geupdate moet worden is zowiezo niet erg handig.

[mbravenboer]

Je kunt met XSLT 2.0 in de toekomst heel fraai met frames werken doordat je meerdere resultaten kunt opleveren bij je transformatie . In XSLT 1.0 is er altijd maar 1 resultaat .

Je kunt je pagina met frames best met XSLT transformeren uit XML, maar de content zal je toch nog apart moeten verzorgen. Uiteraard kan je deze eventueel apart transformeren .

[Verwijderd]

Op dinsdag 08 januari 2002 22:55 schreef mbravenboer het volgende:
Je kunt met XSLT 2.0 in de toekomst heel fraai met frames werken doordat je meerdere resultaten kunt opleveren bij je transformatie . In XSLT 1.0 is er altijd maar 1 resultaat .

Je kunt je pagina met frames best met XSLT transformeren uit XML, maar de content zal je toch nog apart moeten verzorgen. Uiteraard kan je deze eventueel apart transformeren .

Ik denk dat de meesten uit /13 dit niet geheel snappen..
/me idem..

[mbravenboer]

Tizzwat: Ik denk dat de meesten uit /13 dit niet geheel snappen..

Ik zal het ff rustig uitleggen .

Een normale (X)HTML pagina bestaat maar uit 1 XML/html document. Een frameset pagina bestaat er echter uit een XML/html document voor de frameset zelf + voor elk frame een los XML/html document.

In XSLT 1.0 was het onmogelijk om een XML document in 1 keer te transformeren naar een pagina met frames. Een XSLT transformatie toegepast op een XML document levert immers maar 1 document op. Wat je dus wel kon doen: statische of dynamische pagina voor de frameset pagina en aparte pagina's voor de losse frames. In principe kan dit met veel gevogel nog wel gebaseerd op hetzelfde XML document, maar dan zijn er in ieder geval aparte stylesheets nodig...

In XSLT 2.0 komt er echter iets nieuws: je kunt meerdere XML documenten opleveren! Je kunt nu dus een frameset pagina en de pagina's in de frame in 1 keer opleveren! De pagina's waarnaar je in je frameset pagina verwijst kan je dus door diezelfde XSLT stylesheet later genereren .

Deze multiple-result feature is uiteraard niet alleen hiervoor bedacht: het is nog in veel meer situatisch erg makkelijk.

Als ik nog steeds onduidelijk ben: in het de W3C XSLT 2.0 Working Draft staat het nog onduidelijker, maar is er wel een duidelijk voorbeeld met frames .

[Orphix]

Op dinsdag 08 januari 2002 22:26 schreef oh,when? het volgende:
XML en data die vaak geupdate moet worden is zowiezo niet erg handig.

ja ik doelde eigenlijk ook meer op de layout, ik kan soms dingen beetje door elkaar halen. maarja zolang het in het koppie maar goed zit
Maar waarom zou XML en data die vaak verandert niet goed zijn?

_{ps, nog designer nodig voor [topic=370017]}

[mbravenboer]

Orphix: Maar waarom zou XML en data die vaak verandert niet goed zijn?

Goede vraag: XML docs worden juist vaak dynamisch gegeneerd uit een database die erg dynamisch kan zijn... Statische opslag zie je niet zoveel. Meestal wordt XML gebruikt voor communicatie, waarbij het vaak dynamisch wordt opgebouwd.

Tizzwat: niet geheel snappen..

Was het uitgebreidere XSLT 2.0 multiple-result-trees wel duidelijk?

[Orphix]

meer info

Helaas gaat dit (voor zover ik zie) alleen op voor client-side parsing.

[mbravenboer]

Orphix:Helaas gaat dit (voor zover ik zie) alleen op voor client-side parsing.

Hum ja, in deze toepassing inderdaad wel.

Als je server-side gaat transformeren is het verder niet zichtbaar dat de zaak uit een XSLT transformatie komt en is dit dus ook lastig te verwezelijken. Maar goed, je kunt het altijd nog met verschillende stylesheets of een stylesheet met parameters oplossen...

Gelukkig is het ook voor veel andere toepassingen een zinvolle feature .

[oh,when?]

Op dinsdag 08 januari 2002 23:29 schreef mbravenboer het volgende:

[..]

Goede vraag: XML docs worden juist vaak dynamisch gegeneerd uit een database die erg dynamisch kan zijn... Statische opslag zie je niet zoveel. Meestal wordt XML gebruikt voor communicatie, waarbij het vaak dynamisch wordt opgebouwd.
[..]

Ik doelde meer op de transformatie:

data (db) -> XML -> XSLT -> XHTML

Als dadelijk je data alleen HTML word. Hoe ga ik dat netjes uitleggen..ik ben beetje beurs na een lange dag werken (kom net thuis).

Als bij elke request, eerst een vertaalslag word gemaakt naar XML, om uiteindelijk alleen 'maar HTML' te gaan serveren, blijft mijn mening dat dat onnodig veel processorkracht gaat vragen. Mijn recente ervaringen zijn toch dat het parsen van een flinke XML tree wat meer tijd kost dan als je gelijk een html pagina zou gaan serveren. Zeker als je al wat ouder hardware hebt, is dat te merken. Voor data-syndication en data-exchange is het natuurlijk handig dynamisch eerst een XML file te bouwen, of helemaal perfect zou zijn dat je dat via je CMS laat doen, dus bij iedere update publish je een nieuwe XML file. Je wilt uiteindelijk toch zo efficient mogelijk je hardware benutten.

Hoop ik toch nog een beetje duidelijk te zijn

[mbravenboer]

oh,when?: Als bij elke request, eerst een vertaalslag word gemaakt naar XML, om uiteindelijk alleen 'maar HTML' te gaan serveren, blijft mijn mening dat dat onnodig veel processorkracht gaat vragen.

Tja, das inderdaad een probleem. Maar gelukkig is het probleem makkelijk op te lossen: goede caching . Als je database niet is aangepast hoeft de XML data-bron niet opnieuw gemaakt te worden (vaak is dat nog het duurst). Als de XML data-bron niet veranderd is, hoeft er niet opnieuw getransformeerd te worden . Transformeren is over het algemeen razend-snel en daar zit denk ik ook niet het probleem. Het opbouwen van een data-bron uit een database gebeurt vaak met een DOM en das best duur. Er zijn al aardige initiatieven die goede caching toepassen zoals bijvoorbeeld Apache's Cocoon.

Hoop ik toch nog een beetje duidelijk te zijn

Ja hoor, dat lukte prima .

[Verwijderd]

Op dinsdag 08 januari 2002 23:29 schreef mbravenboer het volgende:

Was het uitgebreidere XSLT 2.0 multiple-result-trees wel duidelijk?

Ik begrijp nu na al die antwoorden wel wat je bedoelde..
Toch maar eens een keer zelf die documentatie opzoeken en bekijken..