"optimale" Ajax-Lib

[Multi]

Mahlzeit,
ich weiss, wurde zigmal gestellt, welche Ajax-Lib die beste ist, ich hab aber spezielle Anforderungen.

• sollte sich gut in ein virhandenes OOP-Projekt in PHP integrieren lassen
• Schnittstelle zu anderen Sprachen (C/C++, Perl)
• gute Pflege des Projektes. Eine Lib, die seit Jahren nicht mehr entwickelt wird, bringt mir nix, dann kann ich gleich selber eine schreiben
• kostenlose Nutzung bei kostenlosen Projekten unter der CC
• weite Verbreitung, dass andere Programmierer keine komplett neue AJax-API lernen müssen
• schön schlank, um die Lade- und Rechenzeit zu schonen
• wenn Funktinen zur Javascriptfreien alternative vorhanden sind, umso besser aber nicht zwingend. Das löse ich dann eh im Backend

Momentan hänge ich bei Xajax, was mir auch schon recht gut gefällt. Prototype hab ich mal angesehen, ich will aber möglichst viel Code nach PHP auslagern und nicht im Template haben. Das würde die Erstellung von Templates erschweren, da diese wesentlich komplexer werden müssen.

Ausprobiert hab ich bisher

• Prototype
• Sajax
• Xajax

Sajax gefällt mir schon allein durch die kaum vorhandene Doku nicht. Selbst die Tuturials entsprechen nicht der aktuellen Version. Prototype hat, wie erwähnt, nur die reine Lib, keine API für andere Sprachen.

Und so nebenbei, Google hab ich natürlich bemüht, aber ich hätte gerne persönliche Erfahrungen, die mir Google nur unzureichend liefern kann. Und da hier, erfahrungsgemäss, Leute sind, die wirklich Ahnung haben, gehe ich davon aus, hier die besten Antworten zu bekommen ;)

Grüsse
M.

[EKKi]

Mahlzeit Multi,

Ausprobiert hab ich bisher

• Prototype
• Sajax
• Xajax

Versuch mal jQuery, vielleicht gefällt Dir das ja ... ist sehr flexibel, erweiterbar und arbeitet AFAIK recht gut mit Server-seitigen Sprachen zusammen.

MfG,
EKKi

[suit]

Versuch mal jQuery, vielleicht gefällt Dir das ja ... ist sehr flexibel, erweiterbar und arbeitet AFAIK recht gut mit Server-seitigen Sprachen zusammen.

Es bietet aber keine explizite Schittstelle an - das Dojo-Toolkit z.B. aber schon.

[molily]

Es bietet aber keine explizite Schittstelle an - das Dojo-Toolkit z.B. aber schon.

Was heißt das, Schnittstelle? Was ist damit gemeint?
Wie kann eine Ajax-Bibliothek eine Schnittstelle zu PHP, C, C++, Perl haben?
Wie sieht die Schnittstelle in Dojo aus?

Mathias

[suit]

Was heißt das, Schnittstelle? Was ist damit gemeint?
Wie kann eine Ajax-Bibliothek eine Schnittstelle zu PHP, C, C++, Perl haben?

Zu einem Framework, einer Klasse oder einer Funktiossammlung genauer gesagt und dort werden standardisierte Funktionen verwandt, damit diese miteinander "sprechen" können. Und ich meine jetzt nicht 08/15-XML- oder JSON-Einbindungen.

Wie sieht die Schnittstelle in Dojo aus?

http://o.dojotoolkit.org/book/export/html/98 - am interessantesten ist wohl momentan dojo.data.RdfStore

Scheint jedenfalls sinnvoller zu sein, als sich seine eigenen XML- oder JSON-Schnipsel auf beiden Seiten zusamenzuwursteln. Selbst beschäftigt hab' ich mich damit aber nicht.

Zudem wurde mal angekündigt, Dojo ins Zend-Framework einzubauen und dort entsprechend eine Schnittstelle zwischen den beiden zu schaffen - was daraus geworden ist, weiß ich aber nicht.

[LX]

Bitte berücksichtige, das "AJAX" auf 2 Seiten stattfindet: auf dem Client und auf dem Server - auch wenn dem Client häufig die meiste Aufmerksamkeit zukommt.

Tatsächlich ist AJAX ein Konglomerat zweier Techniken, von denen oft nur eine zur Anwendung kommt: Asynchrones JavaScript und XML. Meistens will man nur HTML-Schnipsel hinzufügen, dann hat man eigentlich AJAH (Ausruf des Begreifens, dass das ja auch ohne XML geht) - oder man möchte JavaScript nachladen, dann bekommt man AJAJ (gesprochen: ei, ei - hauptsächlich deshalb, weil man mit wenig mehr Aufwand auch JSONp verwenden kann, was keine Same-Domain-Policy erfordert).

Die erste von beiden Techniken ist sogar relativ einfach implementiert:

var request = new window.XMLHttpRequest(); // ja, im IE6 geht das nicht, wenn Du fragst, sagen wir Dir auch, wie man das mit ActiveX korrigiert  
if (request) {  
   request.open([type], [url], [async]);  
   request.send([data]);  
   ...  
}

Zur Erläuterung: [type] ist der Request-Typ, meistens GET, manchmal POST; [url] ist die URL der Ressource, die vom Server nachträglich abgeholt werden soll; [async] ist true oder false, je nachdem, ob der Request asynchron gestartet werden soll oder nicht; [data] sind POST-Daten, bei einem GET-Request kann dieser Parameter leer bleiben.

Wenn async false oder nicht angegeben ist, kann danach in request.responseText die Antwort vom Server ausgelesen werden (so eine vorhanden ist). Ansonsten muss man darauf warten, dass das Event request.onreadystatechange auslöst und request.readyState==4 (erledigt) ist, innerhalb des Request-Handlers kann man dann auf request.responseText zugreifen.

Wenn man möchte, kann man sich diese Techniken auch durch Frameworks wie jQuery, mootools, etc. vereinfachen - muss dann aber in Kauf nehmen, dass man zwangsläufig eine Menge überflüssigen Code mitschleppt.

Gruß, LX

[hotti]

hi,

Wenn man möchte, kann man sich diese Techniken auch durch Frameworks wie jQuery, mootools, etc. vereinfachen - muss dann aber in Kauf nehmen, dass man zwangsläufig eine Menge überflüssigen Code mitschleppt.

So isses. Im Prinzip brauchts als Grundbausteine:

• eine Funktion zur Erstellung des XHR-Objekts, kompatibel zu IE //wie Du erwähntest
• eine Funktion, die mit diesem Objekt GET/POST-Requests macht und die Callback-Funktion bedient (wird per Objekt übergeben)

Optional:

• Eine Funktion, die Formulare serialisiert
• Funktionen, die eigene Response-Formate (nicht JSON, nicht XML) in JS-Objekte deserialisiert (-> 1)

Das ist alles keine Hexerei und bei Bedarf beliebig erweiterbar. Serverseitig sollte jeder Ajax-Request genauso ankomen (x-www-urlencoded), dafür hat jede Script-Sprache eigene Parser, die damit zurechtkommen. Zu (1) bedarfsweise eigene Libs schreiben und verwenden.

Horst Senkblei

[LX]

Ich habe mir zu diesem Zwecke selbst ein seeeehr kleines JS-Toolkit namens tiny.js geschrieben, aus dem ich mich regelmäßig "bediene".

Gruß, LX

[hotti]

Ich habe mir zu diesem Zwecke selbst ein seeeehr kleines JS-Toolkit namens tiny.js geschrieben, aus dem ich mich regelmäßig "bediene".

Sieht gut aus, danke!
Horst Brennholz

[LX]

Hallo, Horst!

Sieht gut aus, danke!

Ich danke für die positive Kritik. Die nächste Version ist übrigens bereits in Arbeit. Sie wird "selected Selectors" heißen und austauschbare Selection Engines haben.

Gruß, LX

[Multi]

Bitte berücksichtige, das "AJAX" auf 2 Seiten stattfindet: auf dem Client und auf dem Server - auch wenn dem Client häufig die meiste Aufmerksamkeit zukommt.

Ist mir klar. Einer der Gründe, woieso ich eine fertige Lib benutzen will, ist, dass ich mich genau darum nicht mehr kümmern muss. Ich erzeuge Serverseitig das, was an den CLient geschickt wird und was

Die erste von beiden Techniken ist sogar relativ einfach implementiert:

Ich will nicht selbst so eine Lib pflegen, wenn es genug fertige gibt. Sonst hätte ich nicht nachgefragt, was es so gibt.

Mein Projekt ist jetzt schon sehr komplex und wenn ich nochmal eine komplexe Lib entwickle, brauch ich langsam nen zusätzlichen Programmierer, was nicht ins Budget passt.