XMLHttpRequest

Ich wollte mich mal erkundigen, wie weit das Objekt so verbreitet ist. Wer von euch benutzt ist und was für Erfahrungen habt ihr gesammelt?

Wer nicht weiß, was das ist:
Mit dem XMLHttpRequest lassen sich per Javascript XML-Dokumente nachladen. Es ist also kein kompletter Reload der Seite oder der Einsatz von Frames notwendig, um das Interface zu aktualisieren.

Aber Javascript

Finde ich eine starke Einschränkung für die Spielbarkeit.

JavaScript finde ich klar vertretbar.

Das Objekt ist so weit wie ich weiß auf dem IE als ActiveX, auf Firefox und Opera als normales JS-Objekt verfügbar.

Schau einfach mal auf
http://www.google.com/webhp?complete=1&hl=en
Die nutzen dieses Xml-Objekt und ich finde die daraus entstehenden Möglichkeiten einfach nur geil. Ich habe es gerade durchgetest und es läuft auf den großen 3 Browsern.

EDIT:
Im Google-Quelltext habe ich folgende Zeile gefunden

function jb()
{
var A=null;
try
{
A=new ActiveXObject("Msxml2.XMLHTTP")
}
catch(e)
{try
{
A=new ActiveXObject("Microsoft.XMLHTTP")
}
catch(oc){A=null
}
}
if(!A&&typeof XMLHttpRequest!="undefined")
{
A=new XMLHttpRequest()
}
return A
}

Zu finden in http://www.google.com/ac.js

Original von TheUndeadable
JavaScript finde ich klar vertretbar.

JS finde ich nur vertretbar, wenn es zwar eyecandy + nette features gibt, aber das Spiel in den Hauptfunktionen auch ohne spielbar ist.

Ich mag es sehr, wenn das Spiel in Textbrowsern spielbar ist. ;-)

Ein paar Infos über das Objekt (werde ich mir demnächst mal zur Gemüte führen, danke, dass du mich dran erinnert hast!)

http://developer.apple.com/internet/webcontent/xmlhttpreq.html
"For years, advanced client-side developers have frequently wanted a clean way to maintain a "connection" with the server so that transactions can occur in the background, and newly updated data gets inserted into the current page. Many have tortured themselves by using techniques such as hidden self-refreshing frames and "faceless" Java applets. In lieu of a W3C standard still under development, the Microsoft-born XMLHttpRequest object fills an important gap that should inspire application development creativity. The feature is a welcome addition to Safari."

oder direkt vom eigentlichen Entwickler des Objektes (IE 5)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/xmobjXMLHttpRequest.asp

Nach der Verabschiedung der Spezifikation DOM 3 und der Einbindung in die aktuellen Browser (IE 7 soll dieses bekommen, ich denke mal, dass Firefox und Opera dieses ebenfalls implementieren), soll diese Zwischenlösung abgelöst werden.

Hab bis jetzt noch keinen Grund gefunden, von versteckten Frames wegzukommen.
Funktionieren meiner Meinung nach weit zuverlässiger.

NB: Der neue Google ist geil! Irgendwie tierisch performant!

Gruss

Naja, Dokumaterial findet man schnell mit Google, einfach mal XMLHttpRequest eintippen, und schon finden sich zahlreiche Einsatzbeispiele und Proof-Of-Concepts die nicht selten grade für Browsergame-Programmierer interessant sind.

Ich versuche mich grade an einer erweiterten Version meines kleinen "Mal-Gucken"-Projekts. Das Interface soll, so habe ich es jedenfalls angedacht, aus nur einer XHTML-Seite bestehen, welche über eine JS-Bibliothek und aktualisiert wird. Die Kommunikation zwischen Server und Interface wird über das XMLHttpRequest-Objekt gesteuert. Bis jetzt ließ sich alles wunderbar umsetzen und, wenn ihr mich fragt, weitaus sauberer als mit Frames.

Um mal wieder zum Kern der Sache zu kommen:
Die von mir gekürzten Beiträge:

http://www.google.com/webhp?complete=1&hl=en

Nutzung von Google:
function jb(){
var A=null;
try{
A=new ActiveXObject("Msxml2.XMLHTTP"); }
catch(e) {try{
A=new ActiveXObject("Microsoft.XMLHTTP");
} catch(oc){A=null; }
}

if(!A&&typeof XMLHttpRequest!="undefined")
{A=new XMLHttpRequest();}
return A; }

Zu finden in http://www.google.com/ac.js

Ein paar Infos über das Objekt (werde ich mir demnächst mal zur Gemüte führen, danke, dass du mich dran erinnert hast!)

http://developer.apple.com/internet/webcontent/xmlhttpreq.html
oder direkt vom eigentlichen Entwickler des Objektes (IE 5)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/xmobjXMLHttpRequest.asp

DOM 3 wird Nachfolger, wer sich durchsetzt, wird wie immer die kritische Masse zeigen
Lauffähig mindestens auf den großen 3 Browsern, zumindest auch auf Apples Safari laut Apple Website.

Sauberer als Frames ist die Sache auf jeden Fall und die ersten Tests waren auch erstaunlich schnell von Erfolg gekrönt.

Daher meine Frage:
Wäre es interessant ein Browserspiel komplett auf JavaScript laufen zu lassen und wesentliche Daten nur noch per Xml durch die Gegend zu schicken? Oder ist JavaScript dafür einfach zu umständlich. Damit meine ich gerade die Erstellung von Klassen in JavaScript.

Um da mal n bisschen anderen Input zu liefern.
Die komplette gestaltung eines BGs in JavaScript ist seidt längerem problemlos möglich.
Objektorientierte Entwicklung in JavaScript ist zwar hässlich, aber möglcih.
Selbst ohne OOP in JavaScript lässt sich sehr vieles schon sehr einfach im Browser machen... wos keine Typen gibt, hat man schon von grund auf viel Dynamik

Die Leistungsfähigkeit von javaScript lösungen ist nach meinen Erfahrungen brauchbar.
-> Die Requests funktionieren viel schneller, da weniger Daten. Plus die Präsentation dauert bei den heutigen PCs auch nimmer so lange.
=>>>> kuckt euch mal an, wie schnell der Google Prototyp ist?

Beim praxiseinsatz sind mir jedoch ein paar Punkte negativ aufgefallen.
Es ist extrem mühsam, JavaScript sinnig zu debuggen. Damit meine ich. Sämtliche Pfade abzudecken; dort sämtliches auf herz und nieren durchzuprüfen.
-> Es fehlt schlichtwegs ein sinniges Error Reporting.
=>>> selbst mit Mozilla Debugger und Co.

Die Leistungsfähigkeit ist nach meinen Beobachtungen wie gesagt sehr gross. Durch die Trennung von Darstellung und Daten, lassen sich Gameserver entwickeln, welche extrem viel mehr zu leisten vermögen. ABER: Ein 0815 PHP Progger wird mit diesen Entwicklungen nicht mehr mithalten können.
JA, es gibt in JavaScript genau auch die Probleme, welche es auch in "normalen Programmiersprachen" gibt (und in PHP ned). Beispielsweise kann man unter gewissen Situationen zu "Nebenläufigkeiten" kommen. (Mehrere Threads, welche parallel arbeiten).

Das bedeutet: JavaScript Clients funktionieren nur, wenn man grundsätzlich überlegt an die Sache geht.
-> Zuerst Framework baut, dieses eingiebig testet (dauert bei mir gleich nochmals die Entwicklungszeit). Und danach auf diesem Framework aufbauend arbeitet.

===>>>>> wie du sicher schon lange weist. ICH FINDE JAVA SCRIPT CLIENTS GEIL!!!

Zum Thema XmlObjekte.
Die Probleme zeigen sich hier meiner Meinung bei den Punkten:
- was wenn es Probleme gibt?
- Timeouthandling funktioniert ned sauber
- mehrere parallele Anfragen funktionieren ned sauber
- respektive: wenn ich mehrere parallele anfragen verhindern will, geht das ned sauber
- es gibt Browser, welche damit mühe haben (Man trifft auf unterschiedlichste Konfigurationen).
- Daten können erst abgearbeitet werden, wenn Request beendet

Im Vergleich zu einer Frame Lösung:
- Funktioniert bei allen Browsern.
- Ist merh Code aufwand
- Erlaubt einem Kontrolle über parallele Requests, ...
- Integration von "long Requests" möglich; Client kann während dem Laden schon Daten abarbeiten

Fazit: PROBIERTS SELBER! Investiert hier mal so 50 bis 100 Stunden, sammelt Erfahrungen und dann wisst ihr was davon zu halten ist.
Nimmt mich wunder, ob ihr (wie ich) eine Frame Lösung oder eine XMLObj Lösung wählt.

Mein zwingender grund für Frame Lösung war, dass über die selbe Konstruktion auch ein Push / Pull Handling läuft. Und DIES ist mit XMLObj. leider nicht möglich.

Gruss

Christian