[xml/xsl/js] Xml transformeren en in document invoegen

[Dennis]

Hallo,

Ik wil voor een webapplicatie gebruik maken van xml en xsl. Ik wil dan het volgende doen:

- Xml inlezen in javascript (later met behulp van xmlhttp);
- Xml transformeren met xsl naar een xhtml document;
- Inhoud van xhtml document invoegen in een bestaand document (meer specifiek: in een element).

In eerste instantie was ik even wat aan het spelen met javascript, uitsluitend voor internet explorer, en het inladen en transformeren van document is niet al te spannend (met het XMLDOM object van Microsoft). Ik krijg hier ook gewoon een string uit. Deze string komt inderdaad overeen met de XSL, behalve dan dat er een <?xml version="1.0" encoding="iso-8859-1"?> is toegevoegd. Het hoofdelement van de getransformeerde xml is 'table'.

Het probleem is meteen ook die string. Hoewel het prima werkt als ik document.write gebruik wil ik toch graag gebruik gaan maken van correcte DOM. Ik had gehoopt dat de output van transform op één of andere manier gebruikt kan worden om het 'table'-element te extraheren (getElementsByTagName), maar dat gaat niet. Ook is er geen xml vorm van beschikbaar en weet ik eigenlijk niet hoe je dit zou kunnen wijzigen.

Het lijkt mij dat je op één of andere manier de string wel in xml om zou moeten kunnen zetten, maar ik heb nu nog geen idee hoe ik dat voor elkaar moet krijgen (ook niet na zoeken). Als ik die eenmaal heb kan ik met appendChild neem ik aan gemakkelijk voor elkaar krijgen wat ik wil.

Weet iemand dus hoe ik de output als xml object kan verkrijgen of hoe ik dit op een andere manier op moet lossen?

[crisp]

Klinkt als een recept voor crossbrowser issues. Sowieso is het importeren van nodes vanuit een XML-DOM naar een HTML-DOM al een groot probleem in IE, vnl mbt entities.

Ik denk dat je dit om 3 redenen niet zou moeten willen:
- verschillende approaches noodzakelijk voor verschillende browsers
- relatief veel clientside code noodzakelijk
- slechte performance

en dat nog afgezien van andere problemen die je zeker gaat tegenkomen.

Ontopic: je krijgt vanuit je transformatie een serialised XML document (IE kent geen XHTML mode), dat is inderdaad een string. Vziw kan je ook gewoon serializen naar HTML of een documentFragment. Nu kan je daar natuurlijk weer een DOM-tree van bouwen en vervolgens met importNode werken, maar persoonlijk zou ik gewoon een shortcut nemen en innerHTML gebruiken.

Nog een stapje verder: kan je de XSL-transformatie niet al serverside doen en gewoon arbitraire HTML versturen? Ik neem hier aan dat de XML al beschikbaar is - als die ook nog on the fly gegenereerd moet worden dan zou ik gewoon meteen HTML genereren en de hele XML-santekraam overslaan.

[Dennis]

Dank je voor je opmerking. Liever houd ik de opmaak en inhoud helemaal gescheiden. De xml wordt inderdaad wél on-the-fly opgebouwd. Ik had zelfs eerst een functie die een hele table maakte en heb het daarna omgezet in xml.

Inmiddels is het me eigenlijk al gelukt, met inspiratie uit dit topic met daarin jouw post. Ik haal nu via XmlHttpRequest zowel de xml als de xsl op. De xml doe ik zelfs asynchroon, de xsl is elke keer hetzelfde en wordt ook gecacht. Zodra de xml binnen is, parse ik het geheel door de beide string in te laden als XMLDOM object. Daar komt dan een resultaat uit, waarvan ik een voorgedefinieerd hoofdelement pak en deze via insertAdjacentHTML toevoeg.

Op dit moment heb ik alles nog even Internet Explorer-only, maar ik ga het later nog aanpassen zodat het ook in standard-compliant browsers werkt.

Wat me vanochtend echt hoofdpijn heeft gekost is javascript in je xsl. Dat wordt niet uitgevoerd dus is het onmogelijk. Uiteindelijk maar een scriptje die een hele rits elementen afloopt en aan de hand van de classname een match maakt.

[crisp]

Dennis schreef op woensdag 12 september 2007 @ 11:47:
Dank je voor je opmerking. Liever houd ik de opmaak en inhoud helemaal gescheiden.

Markup dient juist ter ondersteuning van je content, en sec gezien vind ik het logischer om dat al vanaf de server aan je client aan te bieden. Nu geef je semantiekloze XML aan de client en ga je daar vervolgens een imo nutteloze transformatie aan toevoegen.
Opmaak in de zin van presentatie dient inderdaad gescheiden te zijn, maar daar heb je dan ook CSS voor

De xml wordt inderdaad wél on-the-fly opgebouwd. Ik had zelfs eerst een functie die een hele table maakte en heb het daarna omgezet in xml.

Zie ook boven; waarom er dan niet gelijk (X)HTML van maken?

[...]
Wat me vanochtend echt hoofdpijn heeft gekost is javascript in je xsl. Dat wordt niet uitgevoerd dus is het onmogelijk. Uiteindelijk maar een scriptje die een hele rits elementen afloopt en aan de hand van de classname een match maakt.

Je wilt wel opmaak en content scheiden, maar behaviour niet?