Hallo,
mal eine etwas andere Lösung, eine Ebene tiefer als XML, da die von Deinem Server gelieferten Informationen sich eigentlich schon mit HTTP übermitteln lassen:
- Zunaechst habe ich mir ueberlegt, dass der Server stets einen Integer (code) mitschicken sollte, der angibt ob es bei der Verarbeitung des Requests zu Fehlern gekommen ist.
Das macht er schon teilweise, ich würde einfach das bestehende System mitnutzen, nämlich die HTTP Status Codes, an die Du Dein System angelehnt zu haben scheinst. Wenn ich den RFC zu HTTP 1.1 lese, sind die Erläuterungen zu den bestehenden Status Codes lediglich Empfehlungen, zudem kann man den Zahlenraum der Statuscodes erweitern (z.B. 337, 289 ...), d.h. Du könntest zusätzliche Fehlermeldungen zusätzlich zu den bestehenden definieren und vom Server senden lassen. Wobei vieles, eigentlich alles schon von "500 Internal Server Error" abgedeckt sein würde.
Auf der Javascript-Seite hättest Du diesen Status Code dann in XMLHttpRequest.status sofort verfügbar, ohne den Umweg über XML zu gehen.
- Im Fehlerfall wird des weiteren eine "Dump-Id" gesendet (..)
Diese könntest Du dann bei deinen Status Codes der 5xx-Klasse in die Reason-Phrase packen, d.h. zum Beispiel "500 Fehler 45433e33f2". Wie gerade gesagt ist die Reason-Phrase im HTTP-Standard nicht verbindlich, d.h. man kann sie im Prinzip ändern und an eigene Bedürfnisse anpassen, solange das nicht gegen die prinzipielle Information eines 500er-Fehlers verstoßen.
Auf die Reason-Phrase könntest Du dann mit XMLHttpRequest.statusText zugreifen.
<response>
<data id="code">100</data>
Nebenbei halte ich es hier mit MudGuard, ich würde die Information gleich als Element, nicht als ID schreiben. Ist einfach lesbarer.
<data id="result">true</data>
Wobei: Ich würde das Result hier nicht mehr in als Response-Phrase verwenden.
Zusammenfassend:
Bei meiner hypothetischen HTTP-Lösung würde ich den Fehlerstatus schon gleich in HTTP rein kodieren, in Deinem Javascript wirst Du ihn eh abfragen, ob nun als HTTP Status Code oder als eigener, selbstdefinierter Code in der XML-Botschaft. HTTP und seine Status Codes sind nun mal ein bekanntes System, zudem gilt das KISS-Prinzip.
Außerdem hätte das den Vorteil, dass Du in Deiner Javascript-Anwendung gleich die gesamte Fehlerbehandlung mit einem Schlag behandeln kannst. Es gibt ja immer noch die HTTP-Fehler, die nicht von Deiner Server-Anwendung zurückgeliefert werden, wenn zum Beispiel der Webserver Dein PHP/Perl/Python/whatever-Script nicht findet oder nicht ausführen kann. Anstatt einmal eine Fehlerbehandlung für solch generelle Fehler über XMLHttpRequest.status zu basteln und zusätzlich noch eine Fehlerbehandlung mit Deinen eigenen Status Codes, die wahrscheinlich mit "200 OK" gesendet werden und die Du aus dem XML raus fummeln musst.
Wenn kein Fehler auftritt, wird eben wie über HTTP üblich "200 OK" zurückgeliefert, vom Server angeforderte Daten dann in XML oder wie es Dir beliebt.
Tim