[php / xml] DOM xml vs Expat

[Dennis]

Hoi,

Ik ben nu al een poosje bezig met een nieuw project en dit schiet aardig op. Voor dit project gebruik ik XML als output, en vervolgens gebruik ik XSLT als transformatietaal, wat dan zowel serverside als clientside kan gebeuren (detectie wordt ingebouwd).

Nu gaat het mij even over de XML output. Gisteren viel mijn oog op de DOM XML functies.

Op zich wel handig hoe je dan kan omgaan met XML trees, al zat er nog wel een klein onhandigheidje in het OO model van de functies volgens mij, maar daar kijk ik straks nog wel even goed naar .

Nu lijkt het me makkelijk om op termijn over te stappen naar de DOMXML methode ipv gewoon alles 'flat' te echo-en. Ik heb daar dus een paar vraagjes over:


• Is het langzamer output via de DOMXML te laten doen ipv echo te gebruiken en alle xml output zo te doen?
• Is DOMXML wel goed geschikt hiervoor?

In principe lijkt het mij handig om vooral child elements simpel toe te kunnen voegen, en ook om later makkelijk waarden te wijzigen binnen de tree .

Uw tijd gaat nu in .

[ACM]

Ik geloof dat de topictitel zo beter is

[Verwijderd]

Hoewel ik geen ervaring heb met PHP's DOM:

Op zondag 05 mei 2002 14:08 schreef ddc het volgende:<li> Is het langzamer output via de DOMXML te laten doen ipv echo te gebruiken en alle xml output zo te doen?

</li>
Misschien ietsje, maar niet veel als de DOM implementatie een beetje goed is. Voordeel van het door DOM te laten doen is dat het altijd correcte XML oplevert.

<li> Is DOMXML wel goed geschikt hiervoor?

</li>
Dat lijkt me zeker wel, ik gebruik JDOM (Java variant van DOM) voor hetzelfde doeleinde, en dat werkt best lekker.

[Dennis]

Zef:
Wat ik zelf een groot voordeel vind ik dus wat ik zei is dat ik later makkelijk dingen kan aanpassen.

Als ik bijvoorbeeld ergens in mn XML tree de parsetijd wil weergeven, maar daarna nog enkele functies wil doen, kan ik later met de DOMXML makkelijk dat soort waarden van elementen vervangen, terwijl ik dat soort dingen nu doe met een str_replace, dan is de DOMXML oplossing toch netter .

[Dennis]

Ik heb net nog even wat leuke artikelen gelezen (o.a. deze, en zag o.a. ook idd een beetje een slordige OO in de DOM XML functies, maar ik denk dat ik dat kan wegwerken door gewoon met objecten in objecten te werken .

Dus ipv:

PHP:

<?$obj_xml = xmldoc($xml);$root = $obj_xml->root();$root->new_child("new","test");?>

Gewoon:

PHP:

<?$obj_xml = xmldoc($xml);$obj_xml->root->new_child("new","test");?>

, wat naar mijn mening veel netter is, en waarin je dus ook het aantal variabelen kan beperken. In mijn boek dat ik hier thuis heb (deze) wordt trouwens ook wat dieper ingegaan op DOM (alsook op SAX en PRAX).

Wat trouwens ook een leuke vraag is waar ik ook naar benieuwd ben is deze. Misschien dat iemand hier daar het antwoord op weet.

[Rense Klinkenberg]

Als je pur naar tijd zal kijken, zal domxml langzamer gaan dan echo'en. Zoals je al zei heeft domxml echter het voordeel dat je het makkelijker aan kan passen en je code netter en logischer in elkaar kan zitten.

Wat betreft serverside xsl transformaties, zou ik met het oog op de langere termijn alvast domxml gebruiken.

Momenteel werken xslt's in php een beetje ranzig, omdat je vaak met domxml een mooi dom model opbouwd, die platslaat en dan door de xslt processor (Sablot) heenhaalt. Bij de volgende (of misschien de dan volgende) versies van php zal er echter een uitbreiding komen op de domxml extensie in de vorm van domxslt. Hiermee kan je het dom mooi heel laten. Het is zelf zo erg dat je ook een do terugkrijgt van je transformatie.

Met het oog op de toekomst ericht, is domxml dus best wel een goede keuze.

[Dennis]

thanx freak007!

Ik heb al flink wat aangeklooid met XSLT, en probleem met Sablotron is idd dat het niet echt optimaal werkt. Vanmiddag was ik nog ff wat aan het testen met Sablotron, maar die haalt de meest simpele transformaties al met moeite.

In het project zelf was ik nog niet eens toegekomen aan de serverside transformatie (alle functies zijn al af qua aanroepen, alleen het werkelijk transformeren gebeurt nog niet) en daarom was ik dus vanmiddag aan het testen.

Sablotron is ook niet echt gebouwd op het DOM model, je hebt zelfs al een ingewikkelde methode nodig om een variabele erin te gebruiken.

Nogwel een vraagje aan jou, wat is het voordeel dat ik de output (in dit geval even XHTML) terug krijg als DOM object? Ik denk dat het dan niet echt zin heeft, maar jij doelt vast meer op XML+XML->XML transformaties gok ik zo .

[xshredx]

Ik zou domxml gebruiken boven het echoën van je xml.
Ten eerste lijkt me dat makkelijker en netter (argument is al aangehaald), maar het is misschien ook een goeie werkwijze naar de toekomst toe.
Er wordt op dit ogenblik op de php-dev mailinglist gebabbeld over een interfaces implementatie voor php (die interfaces zijn een set van c functies die zouden toelaten dat verschillende extensies gebruik maken van dezelfde userspace data). Hiermee zou het bijvoorbeeld mogelijk zijn dat een XML document dat je creëert met de DOMXML extensie meteen naar xhtml geconverteerd wordt via de XSLT extensie, zonder de data eerst naar en van een string representatie te converteren.
Men mikt erop om dit al in PHP 5 te krijgen.

(zie ook: http://www.zend.com/lists/php-dev/200204/msg01076.html )

[Dennis]

Wat je hier zei is eigenlijk hetzelfde als freak007 al zei. ACM bevestigde ook gisteren dat Expat in volgende PHP releases al wordt beperkt ('depricated') (uitgesloten zal het denk ik nooit worden).

Ik ga vandaag nog even kijken naar de XML mogelijkheden en even wat testen doen met trees en childs toevoegen binnen die trees.

Waar DOMXML ook wel heel handig kan zijn is WAP, zat ik nu aan te denken, omdat WAP natuurlijk ook gewoon een vorm is van XML content .

[Rense Klinkenberg]

Op maandag 06 mei 2002 08:03 schreef ddc het volgende:
Wat je hier zei is eigenlijk hetzelfde als freak007 al zei. ACM bevestigde ook gisteren dat Expat in volgende PHP releases al wordt beperkt ('depricated') (uitgesloten zal het denk ik nooit worden).

Nee dat is iets anders. Wat ik bedoelde was de uitbreiding van de domxml extensie.

Gisteren was ik toevallig de standaard 4.2.0 versie aan het compileren en zag dat ze die uitbreiding toch wel al hadden doorgevoerd naar de release. Goed nieuws dus

Even kort hoe je het kan installeren:

• Haal libxml2 en libxslt op van http://www.xmlsoft.org/downloads.html. Waarschijnlijk had je libxml2 al, maar updaten is ook nooit erg
• Compileer libxml2 en daarna libxslt.
• Voeg de extra configuratie opties toe aan php:
  
  code:
  

  --with-xslt[=DIR]
  --with-exslt[=DIR]

• en compileer php even opnieuw

Als het goed is heb je nu een paar nieuwe functies in php zitten en is de informatie van je phpinfo ook iets geupdate bij de domxml extensie (zie mijn phpinfo)

Voor wat uitleg van de nieuwe functies kan je kijken op http://rense.nl.nu/tutorial/php/domxml/domxml_xslt.html

Nogwel een vraagje aan jou, wat is het voordeel dat ik de output (in dit geval even XHTML) terug krijg als DOM object? Ik denk dat het dan niet echt zin heeft, maar jij doelt vast meer op XML+XML->XML transformaties gok ik zo .

Wat je nu heel makkelijk kan doen is het uitvoeren van verschillende transformaties achter elkaar. Stel dat je een mooie xsl template hebt gemaakt voor een slashdot newstracker. Als je dat zou willen uitbreiden met het nieuws van t.net, zal je een nieuwe template moeten schrijven, omdat de xml heel anders in elkaar steekt.

Wat je nu zou kunnen doen is de turbotracker van t.net eerst transformeren naar het formaat zoals ze dat op slashdot gebruiken en daarna invoegoen in de dom die je vervolgens transformeert naar (x)html / wml / ...

[whitehouse]

maar tja.. dan heb je de libxml2 en alle andere modules geinstalleerd, dan moet je ook verwachten dat de provider dit heeft .. toch ??