[AJAX] Communiceren in xml (Client --> server)

[Verwijderd]

Ik ben bezig met een ajax applicatie die content en gegevens vanaf een php backend laadt wanneer dit nodig is. Ik wil dat de communicatie tussen beide volledig in XML is. Tot nu toe is het me echter alleen gelukt om de communicatie vanaf de server in xml te zetten, requests naar de server lukt me echter alleen als 'normale' post. De meeste tutorials werken ook met GET of POST variabelen. Hoe kan ik een xmlDocument naar de server sturen en deze opvangen in php? (XML document bouwen en parsen lukt wel)

[Erkens]

Zodra je met JavaScript je XML document hebt kan je deze via POST meesturen:

JavaScript:

var xmlElem;
var xmlDoc;

if(document.implementation.createDocument) 
{
  xmlDoc = document.implementation.createDocument("", "rootelement", null);
  xmlElem = xmlDoc.documentElement;
}
else 
{
  xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
  var root = xmlDoc.createDocumentFragment();
  xmlElem = xmlDoc.createElement("rootelement");
  root.appendChild(xmlElem);
  xmlDoc.appendChild(root);
}

// bouw hier je xml

request.open("POST", "scriptje.php", true);
request.send(xmlDoc);

En aan de PHP kant vang je het zo op:

PHP:

$xml = "";
$putData = fopen("php://input", "r");
while($block = fread($putData, 1024))
{
  $xml .= $block;
}
fclose($putData);

werkt prima

[Verwijderd]

Ah bedankt!

Dat opvangen in PHP was dus nog niet gelukt, ik ga het van de week maar eens toepassen! Requests opvragen mbv GET lukte nog wel, maar een hele shoppingcart naar de server sturen is wat lastiger

[Verwijderd]

mja, waarom je eigen xml taal maken die niemand snapt? gebruik dan SOAP voor je communicatie, zit standaard in php en je hoeft er aan de JS kant alleen een klein schilletje extra voor te bouwen. Het kan zo transparant dat je PHP functies als method van een JS object aan te roepen zijn als je wilt

[Erkens]

Verwijderd schreef op woensdag 04 oktober 2006 @ 08:01:
mja, waarom je eigen xml taal maken die niemand snapt? gebruik dan SOAP voor je communicatie, zit standaard in php en je hoeft er aan de JS kant alleen een klein schilletje extra voor te bouwen. Het kan zo transparant dat je PHP functies als method van een JS object aan te roepen zijn als je wilt

ehm, omdat XML hiervoor gemaakt is? SOAP gebruikt ook gewoon XML, en een bijkomend nadeel van SOAP is dat het voor nog meer overhead zorgt.

Overigens zit "SOAP" helemaal niet standaard in PHP, maar moet deze compile time erbij geprakt worden, iets wat nog altijd niet standaard is (iig niet in de mainstream linux distro's waar PHP meegeleverd word) en de PHP documentatie zegt het ook al: (no version information, might be only in CVS)

[Verwijderd]

Erkens schreef op woensdag 04 oktober 2006 @ 08:22:
[...]

ehm, omdat XML hiervoor gemaakt is? SOAP gebruikt ook gewoon XML, en een bijkomend nadeel van SOAP is dat het voor nog meer overhead zorgt.

Overigens zit "SOAP" helemaal niet standaard in PHP, maar moet deze compile time erbij geprakt worden, iets wat nog altijd niet standaard is (iig niet in de mainstream linux distro's waar PHP meegeleverd word) en de PHP documentatie zegt het ook al: (no version information, might be only in CVS)

Dus? Je laat je beperken omdat het nog niet standaard inzit? Een beetje tweaker kan daar toch omheen? Ik gebruik al een tijdje Nusoap (http://sourceforge.net/projects/nusoap/). Heel handig.

[Verwijderd]

EDIT: nee laat maar ..

[ Voor 90% gewijzigd door Verwijderd op 04-10-2006 10:05 ]

[Erkens]

Verwijderd schreef op woensdag 04 oktober 2006 @ 09:48:
Dus? Je laat je beperken omdat het nog niet standaard inzit?

Nee natuurlijk niet, maar voor simpele AJAX toepassingen is SOAP gewoon overkill.
Maar dan nog wil je niet altijd tig duizend dependancies hebben

Een beetje tweaker kan daar toch omheen? Ik gebruik al een tijdje Nusoap (http://sourceforge.net/projects/nusoap/). Heel handig.

Kan best handig zijn, maar een project gebruiken wat in een jaar tijd geen updates heeft gehad en nog geen stable versie heeft wil je gewoon niet in een productie omgeving draaien, zeker niet als het totaal overbodig is. Ik zie namelijk op het sourceforge forum van dat project dat er mensen problemen hebben met PHP5 omdat daar blijkbaar die SOAP al in zit en NuSOAP gebruikt blijkbaar dezelfde classnames, nee, lekker handig, probeer dat maar eens aan je klanten te verkopen

[Verwijderd]

het is niet de bedoeling van xml dat iedereen z'n eigen taaltjes erin gaat schrijven, dan ga je compleet aan compatibiliteit, uitbreidbaarheid en standaardisatie voorbij. Als je een communicatietaal op xml gebaseerd wil hebben, pak dan een bestaande namespace en verzin niet je eigen. SOAP is een mooi voorbeeld van een bestaande namespace.

En waar zit de overhead in SOAP ten opzichte van je eigen XML protocol? dat zie ik niet zo. Wat ik wel zie is dat je gebruik kan maken van "standaard" php functies die wellicht sneller zijn dan wat je zelf maakt

[Erkens]

Verwijderd schreef op woensdag 04 oktober 2006 @ 12:05:
het is niet de bedoeling van xml dat iedereen z'n eigen taaltjes erin gaat schrijven, dan ga je compleet aan compatibiliteit, uitbreidbaarheid en standaardisatie voorbij. Als je een communicatietaal op xml gebaseerd wil hebben, pak dan een bestaande namespace en verzin niet je eigen. SOAP is een mooi voorbeeld van een bestaande namespace.

Met XML kan je structuur aanbrengen in data die je bijvoorbeeld gebruikt voor transport. Ik zie niet in waarom je voor geen eigen namespace mag verzinnen, het is imo juist beter om je eigen namespace te gebruiken!

Overigens SOAP is meer dan slechts een namespace, maar dat wist je natuurlijk wel

En waar zit de overhead in SOAP ten opzichte van je eigen XML protocol? dat zie ik niet zo. Wat ik wel zie is dat je gebruik kan maken van "standaard" php functies die wellicht sneller zijn dan wat je zelf maakt

Nooit met SOAP gewerkt in JavaScript?

[Verwijderd]

Verwijderd schreef op woensdag 04 oktober 2006 @ 12:05:
het is niet de bedoeling van xml dat iedereen z'n eigen taaltjes erin gaat schrijven,

Ik verschil daarin met jou van mening. Wat mij betreft is dat absoluut wel de bedoeling.

[Verwijderd]

SOAP in javascript is hetzelfde als wat voor andere xmltaal via een httprequest dan ook, een kwestie van je xml doc in elkaar proppen en verzenden, het antwoord vice versa.

waarom is het beter om je eigen taal te verzinnen? dat zie ik echt niet. Als iedereen z'n eigen communicatietaaltjes gaat verzinnen, en je wilt op de duur systemen combineren/overdragen/uitbreiden/whatever, hoe ga je dat dan ooit klaarspelen? Het grote voordeel van standaarden is juist dat ze standaard zijn. Als iedereen maar wat gaat lullen, verstaat niemand mekaar, semantic web is geen politiek het is hier wel belangrijk dat je mekaar begrijpt

Als je het uitbreid naar RDF bijvoorbeeld, waar alles draait om namespace beheer: je gaat toch ook geen nieuwe vocabs maken als die grotendeels al in de dublin core zitten of in FOAF of waar dan ook in? Hoe kan je ooit weten of jouw foo:integer hetzelfde is als xsd:int?

[ Voor 8% gewijzigd door Verwijderd op 05-10-2006 08:21 ]

[Erkens]

Verwijderd schreef op donderdag 05 oktober 2006 @ 08:20:
SOAP in javascript is hetzelfde als wat voor andere xmltaal via een httprequest dan ook, een kwestie van je xml doc in elkaar proppen en verzenden, het antwoord vice versa.

Ooit SOAP gepraat met JavaScript? Dan weet je meteen wat ik zeg dat SOAP niet handig is

waarom is het beter om je eigen taal te verzinnen? dat zie ik echt niet. Als iedereen z'n eigen communicatietaaltjes gaat verzinnen, en je wilt op de duur systemen combineren/overdragen/uitbreiden/whatever, hoe ga je dat dan ooit klaarspelen? Het grote voordeel van standaarden is juist dat ze standaard zijn. Als iedereen maar wat gaat lullen, verstaat niemand mekaar, semantic web is geen politiek het is hier wel belangrijk dat je mekaar begrijpt

XML is de taal die je spreekt, SOAP is slechts een implementatie daarvan, hoewel ik eerder de voorkeur geef aan XML-RPC

Hoe kan je ooit weten of jouw foo:integer hetzelfde is als xsd:int?

dat is niet relevant in deze situatie, je moet kijken welke methode handig is voor je doel, en niet je doel aanpassen op je oplossing.

Als ik dit zie dan weet ik wel wat ik kies voor een simpele AJAX toepassing

SOAP:

XML:

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetails xmlns="http://voorbeeldje/">
       <productID>1234</productID>
     </getProductDetails>
   </soap:Body>
 </soap:Envelope>

XML-RPC:

XML:

<methodCall>
  <methodName>getProductDetails</methodName>
  <params>
    <param>
        <value><int>1234</int></value>
    </param>
  </params>
</methodCall>

XML:

XML:

<call>
  <get method="getProductDetails">
    <id>1234</id>
  </get>
</call>

[Verwijderd]

xml is geen taal, maar een grammaticaset, zolang je een ander de woorden niet leert blijft het onverstaanbaar XML-RPC of SOAP is mij om het even, maar die 3 regels winst van je "eigen" spec wegen m.i. compleet niet op tegen het gebrek aan compatibiliteit/overdraagbaarheid etc (da's een mening)

Ik heb wel eens een SOAP wrapper gemaakt in js ja, en ik zie niet in hoe deze zou verschillen van ene wrapper voor je eigen taal. Misschien dat je daar wat verder op kan ingaan? want de rest (of je voor een standaard gaat of niet) is denk ik een kwestie van meningen, daar komen we toch niet uit

overigens: SOAP met js is per definitie AJAX he

[ Voor 4% gewijzigd door Verwijderd op 05-10-2006 09:47 ]

[djluc]

Ik heb er geen praktijk ervaring mee maar toch lijkt he me zeker niet verkeerd om te gebruiken. Allerlei zaken als foutmeldingen e.d. zitten er al standaard op een basis manier in geimplementeerd. Als ik dus een willekeurige applicatie pak en zie dat zo'n error langs komt weet ik meteen in welke richting ik moet gaan zoeken. Ik kan ook specifiek gaan zoeken op die errors als ik een onbekende applicatie moet gaan debuggen. Klinkt zeker niet verkeerd.

In het algemeen schrijf je toch een simpele class waarmee je alle AJAX requests uitvoert. Het is dan toch geen enkel probleem om eenmalig even die error-verwerking e.d. te implementeren? Anders moet je zelf een standaard gaan implementeren, documenteren enzovoorts, beetje zonde als dit al gedaan is.

Wat ik jammer vind is dat de standaard niet verder gaat, ze verdelen de header/body maar verder mag je doen wat je zelf wilt. Een aantal best practices zou niet verkeerd zijn, al zijn het maar simpele shoppingcart voorbeelden, zodat iedereen een beetje dezelfde benamingen en werkwijze gaat gebruiken.

[Verwijderd]

Ik had deze discussie een beetje gemist, maar ik heb voor mijn site gewoon een javascript frontend en een php backend die met elkaar moeten communiceren. Dat gebeurt nu dmv van get methods waarbij xml terug gestuurd wordt in mijn eigen taaltje, zoals jullie dat noemen. Ik heb alleen voor het sturen van de inhoud van een shopping cart xml nodig in de richting van de server. Ik dacht eraan om implementatie (met oog op de launch datum) nog in mijn eigen korte taal te doen, ik zal later mss nog wel naar soap kijken als jullie beweren dat dat zoveel handiger is.

Overigens, waarom zou gestandadiseerde taal nodig zijn als de front-end en backend specifiek voor elkaar geschreven zijn? Alles wordt nu netjes afgehandeld door mijn eigen javascript libraries.

[JKVA]

Verwijderd schreef op zondag 22 oktober 2006 @ 14:31:
Overigens, waarom zou gestandadiseerde taal nodig zijn als de front-end en backend specifiek voor elkaar geschreven zijn? Alles wordt nu netjes afgehandeld door mijn eigen javascript libraries.

Waarom zou je in PHP of Java programmeren als je ook zelf een taaltje in elkaar kunt zetten die precies doet wat je wilt?

Je steekt er tenslotte meer tijd in dan in je eigenlijke project, niemand behalve jijzelf begrijpt er iets van en je zult nooit hetzelfde kwaliteitsniveau halen.

Kortom, waarom loopt iedereen altijd zo te bashen tegen standaarden? Die standaarden zijn er niet voor niets en het is niet zo dat er niet over nagedacht is ofzo.

[Verwijderd]

Wat een drukte om een XML implementatie.

XML in combinatie met een schema laat je juist vrij in het maken van je eigen regels. Het leuke van de XML standaard is dat het door derden in combinatie met het schema 100% te begrijpen is.

Sterker nog een xml file als:

XML:

<call> 
  <get method="getProductDetails"> 
    <id>1234</id> 
  </get> 
</call>

Daarvoor heeft niemand een schema nodig maar is zo al duidelijk wat er bedoeld wordt.

[Rekcor]

Ik gebruik gewoon de xajax library (http://www.xajaxproject.org/).

Die communiceert ook met XML. Waarom het wiel voor de n-de keer uitvinden?

[ Voor 13% gewijzigd door Rekcor op 23-10-2006 11:56 ]

[Verwijderd]

Verwijderd schreef op maandag 23 oktober 2006 @ 11:09:
Wat een drukte om een XML implementatie.

XML in combinatie met een schema laat je juist vrij in het maken van je eigen regels. Het leuke van de XML standaard is dat het door derden in combinatie met het schema 100% te begrijpen is.

Sterker nog een xml file als:

XML:

<call> 
  <get method="getProductDetails"> 
    <id>1234</id> 
  </get> 
</call>

Daarvoor heeft niemand een schema nodig maar is zo al duidelijk wat er bedoeld wordt.

voor een mens wel, maar voor een machine niet. Ook al is de functie getProductDetails aan de server kant wel geimplementeerd, je zal toch een stuk middleware moeten schrijven die je protocol vertaald. Met een standaard hoeft dat niet

[JKVA]

Precies, en als je gebruikmaakt van een standaard (zoals SOAP) dan heb je ook nog de kans dat iemand anders dat stukje middleware al voor je gemaakt heeft. Zoals wederom bij SOAP het geval is.

Ik moet er wel nij zeggen, ik ken PHP niet tot in detail, maar het lijkt me wel dat er een SOAP PHP library is.