[php/xml] XML preparsen

[rig0r]

Hoi,

Ik heb een xml file die ik zeg maar wil preparsen en daar een nieuwe xml file uit wil toveren. De xml file die ik als input gebruik bevat namelijk bepaalde tags die gereplaced moeten gaan worden met waarden uit een database. De overige tags die daar niks mee te maken hebben moeten genegeerd worden.

Ik heb dus de handlers gedefineerd en check of het om een relevante tag gaat of niet. Zoja, dan moet daar wat gereplaced gaan worden, zonee dan negeren en de betreffende tag + data + attributen in de xml output meenemen.

Probleem is alleen : hoe haal ik binnen die handlers de oorspronkelijke xml data (dus gewoon plain) tevoorschijn, zodat ik deze kan appenden aan de gepre-parste xml output

[Verwijderd]

Die kan je toch gewoon ophalen door de file te parsen met een xml parser?

[rig0r]

Nee, want dan krijg je de tagnames en data, ik wil em juist (ook) in raw format hebben.

[RobIII]

Kun je 'm niet inlezen als textfile en dan gewoon string-replaces uitvoeren?

Dus replace "<dezenode>" met "<dienode>" en "</dezenode>" met "</dienode>". Als je daar een mooi subje van maakt ben je zo klaar...
't is maar een idee...

[Verwijderd]

Volgens mij wil rig)r dat juist niet, hij wil met de normale xml handlers zijn xml verwerken. Persoonlijk lijkt het me ook niet erg netjes om XML als string te behandelen...

[drm]

rig0r:
Probleem is alleen : hoe haal ik binnen die handlers de oorspronkelijke xml data (dus gewoon plain) tevoorschijn, zodat ik deze kan appenden aan de gepre-parste xml output

offtopic:
De eerste quote die mij te binnen schiet als ik dit lees is:

Xml Joke:
Question: When should I use XML?
Answer: When you need a buzzword in your resume.

---

De allereerste oplossing die mij te binnen schiet is XSLT. Dit is de ideale techniek als het gaat om transformeren van XML naar een andere vorm van XML en dat is volgens mij waar je heen wilt

---

Wat je ook kunt doen is mbv. de xml parser een (abstracte) boom maken die de hele Xml boom representeert. Vervolgens kun je in die boom knutselen wat je wilt (adhv elementnames teksten vervangen etc.) om vervolgens de boom weer terug te converteren naar XML.

---

Tot slot zou je een wat ranziger (quick fix) oplossing kunnen gebruiken die ook in de manual genoemd wordt in een soortgelijke constructie. Denk daarbij ongeveer aan het volgende:

PHP:

$file = "data.xml";

$g_currentElement = array ();

function startElement($parser, $name, $attrs) {
    global $g_currentElement;
    array_push ( $current_element, $name );
    // print hier de tag inclusief attributen
}

function endElement($parser, $name) {
    global $g_currentElement;
    array_pop ( $current_element );
}

function characterData($parser, $data) {
    global $g_currentElement;
    $elementName = array_pop ( $g_currentElement );
    if ( $elementName == 'dit-is-een-speciale' ) {
       // doe hier iets speciaals
    }
    
    array_push ( $g_currentElement, $elementName );
}

Iets van die strekking. Overigens is dat gebruik van globals allesbehalve netjes te noemen, en kun je het zaakje dan beter in een class wrappen.

Sowieso is bij de 2^e oplossing die ik noemde het aan te raden het hele zaakje in een klassenstructuur te gaan onderbrengen ( XmlElementNode, XmlTextNode, XmlAttribute, etcetera).

[hobbit_be]

ik snap gewoon niet wat ie wil - heb de vraag nou al 3 keer doorgelezen en steeds geen lichtje branden. kun je niet effe een mini voorbeeldje geven. ie Step1, 2, 3 enzo.

[rig0r]

Ok ik zal et ff verder uitdiepen

Voor een webapp wil ik voor de input forms een combinatie van XML en XSLT gebruiken, maar de input forms moeten uiteraard ook database gegevens kunnen bevatten. Ik wil dus zelf een extensie bouwen die benodigde data ophaalt en erin plakt.

(Ingekort) voorbeeld XML bestand :

XML:

<form>
  <id>profile</id>
  <xsql:query>select * from users where usr_id=:usr_id</xsql:query>
  <input>
    <type>text</type>
    <id>username</id>
    <caption>User Name :</caption>
    <value><xsql:getresult column="usr_name"/></value>
  </input>
</form> 

Stap 1 is het parsen van deze XML file en het vervangen van de xsql: tags met de gerelateerde database data.

Na stap 1 heb je dit :

XML:

<form>
  <id>profile</id>
  <input>
    <type>text</type>
    <id>username</id>
    <caption>User Name :</caption>
    <value>Pietje</value>
  </input>
</form> 

Stap 2 is het transformen van deze XML naar XHTML middels XSLT, dus met xslt_process(). Na deze stap krijg je dan zoiets als dit (versimpeld) :

XHTML:

<table border="0">
  <form id="profile">
    <tr>
      <td>User Name :</td>
      <td><input id="username" type="text" value="Pietje"/ ></td>
    </tr>
  </form>
</table>

Dit is het eindresultaat.

Ik zit al te peinzen of dit misschien in 1 stap kan, maar ik wil perse 1 XSL template kunnen gebruiken voor meerdere form XML's, dus een combinatie van deze 2 in 1 file is eigenlijk geen optie.

@RobIII:
Daar had ik ook over nagedacht, maar dan loop je tegen een aantal beperkingen aan, het is helaas niet zo simpel als een simpele search & replace.

@drm:
Hmm ik moet me toch wat meer in XSLT verdiepen denk ik, volgens mij kan dat meer dan ik denk dat het kan
Ik heb het zaakje overigens al in een class hangen nu dus die globals zijn foetsie.

[hobbit_be]

hmm dit is precies wat Cocoon doet (maar dat is Java en nog wel iets uitgebreider ).

maar daar is de base xml wel net iets anders:

code:

<esql:query query="select....">
    <input>
       ....
    <value><esql:get-string column="...: /></value>
</>

Deze cocoon werkt ook met XForms (dus een heel systeem om ook HTML input enzo + validation). Mischien de moeite waard om eens te kijken hoe ze dat doen - we gebruiken het voor een website hier en werkt best. (ook transparent use van XML-DB enzovoorts).

[rig0r]

Woei geinig, zal daar es even een blik op werpen. Maar dat XForms staat toch nog helemaal in de kinderschoenen ? Ik dacht eigenlijk dat het nu wachten is op browser support voor XForms...

Ik ben op zich wel een beetje bang dat deze techniek een beetje teveel overhead is voor het op je scherm kwakken van een formuliertje, maarja er is maar 1 manier om dat uit te vinden. Bovendien heeft deze techniek toch wel een behoorlijk aantal voordelen.

Jij bedoelt deze Cocoon neem ik aan ?

[hobbit_be]

rig0r schreef op 07 juni 2003 @ 14:01:
Woei geinig, zal daar es even een blik op werpen. Maar dat XForms staat toch nog helemaal in de kinderschoenen ? Ik dacht eigenlijk dat het nu wachten is op browser support voor XForms...

Yep Cocoon gebruikt zijn 'eigen' versie - maar die leunt hard aan - persoonlijk heb ik het zelf niet zoveel voor die w3c standaarden (zeker niet bij een 1.0 versie).

Ik ben op zich wel een beetje bang dat deze techniek een beetje teveel overhead is voor het op je scherm kwakken van een formuliertje, maarja er is maar 1 manier om dat uit te vinden. Bovendien heeft deze techniek toch wel een behoorlijk aantal voordelen.

ja overhead is het wel. Maar bij cocoon gebeurt en nog iets speciaals op het einde: er word een java servlet van gemaakt wat wil zeggen dat het eigenlijk een code generator is (je kan bijvoorbeeld je eigen logica dmv tags, maar ook door pure java code ertussen knallen) werken wat er uiteindelijk voor zorgt dat het slechts een keer 'ziet' hoe ie het moet opbouwen en daarna is het allemaal parsed code (dus sneller dan PHP , heel wat zelfs, aangezien eens een servlet opgestart is die razend snel zijn). Ik denk ook dat die een weg 'forward' is.

Overigens worden de 'forms' dan zo leuk en transparent erop gezet dat je bevalve in je je laatste XSL er pas Input van gemaakt worden (maar dat doet ie dan weer voor jouw door die XForms - bijna perfecte abstractie. (en natuurlijk wordt je veronderstelt om met beans te werken zodat je zelfs geen SQL meer moet kloppen, ook dat doet ie voor jouw). We hebben er eigenlijk weining problemen mee gehad behalve het geheugen gebruik (we hebben onze server provider gewoon betaalt voor meer mem ). Maar qua adaptibiliteit is het nu gewoon belachelijk goed (en ook rock solid)

Jij bedoelt deze Cocoon neem ik aan ?

idd. Je zult wel een WebApp server nodig hebben (Tomcat ook gratis) dus het is wel geen 'kleine' en 'snel' spul (ie je hebt ZEKER 256MB aan geheugen nodig in een productie / server environment)