How to start... Ajax

[lina-]

moin :)

Ich werde mich demnächst näher mit Ajax beschäftigen (juhu *g*) und würde gern wissen, ob damit jemand schon Erfahrungen gesammelt hat.

Speziell würde ich gern wissen, welche Bücher empfehlenswert sind (Vorkenntnisse in Javascript, HTML und CSS sind freilich vorhanden - ich brauch also kein Anfängerbuch).
Ebenso interessant würde ich Linktipps zu besonders guten Tutorials finden.

Das Projekt, das mit Ajax neu aufgesetzt werden soll ist eine relativ große Webanwendung, die sehr Guilastig ist. Denke da ist das neue Buzzword "Ajax" genau das richtige? Oder?

liebe Grüße aus Berlin
lina-

[FraFu]

Hallo!

Das Projekt, das mit Ajax neu aufgesetzt werden soll ist eine relativ große Webanwendung, die sehr Guilastig ist. Denke da ist das neue Buzzword "Ajax" genau das richtige? Oder?

Im großen Umfang verwende ichs nur in Intranetanwendungen, wo ich genau weiß, welche Clients im Einsatz sind.

Sehr empfehlen kann ich die prototype Library

mfg
  frafu

[lina-]

moin FraFu :)

Im großen Umfang verwende ichs nur in Intranetanwendungen, wo ich genau weiß, welche Clients im Einsatz sind.

Da diese Anwendung nur für unsere Kunden erreichbar ist, kann ich einigermaßen einschränken welche Clients unterwegs sind. :)
Ansonsten wäre Ajax wohl nicht so ganz das gelbe vom Ei. Hab gelesen, dass nicht alle Browser (insb. die älteren) das nicht unterstützen.

Sehr empfehlen kann ich die prototype Library

Das ist mal ein klasse Link! Vielen Dank :)

liebe Grüße aus Berlin
lina-

[Cybaer]

Hi,

Ansonsten wäre Ajax wohl nicht so ganz das gelbe vom Ei. Hab gelesen, dass nicht alle Browser (insb. die älteren) das nicht unterstützen.

Na ja, viele Browser der Generation "Netscape 4" sind sicherlich nicht mehr im Einsatz. Aber wie für alle clientseitige Techniken gilt auch bei Ajax: Abschaltbar, also nichts damit machen, was *zwingend* machbar sein muß.

Bei Ajax speziell kommt noch hinzu, daß es beim IE auf ActiveX basiert. Und selbst wenn JS nicht deaktiviert ist, ActiveX ist *so* unsicher, daß man eher mit dem Klammerbeutel gepudert sein muß, als daß man das aktiviert hat. =:-o

Und da man mittels eines unsichtbaren (I)Frames und JS eine ebensolche Funktionalität (unter Verzicht auf ActiveX!) erreichen kann, halte ich Ajax für ziemlich verzichtbar ...

Gruß, Cybaer

[lina-]

moin Cybaer :)

Na ja, viele Browser der Generation "Netscape 4" sind sicherlich nicht mehr im Einsatz. Aber wie für alle clientseitige Techniken gilt auch bei Ajax: Abschaltbar, also nichts damit machen, was *zwingend* machbar sein muß.

Bei Ajax speziell kommt noch hinzu, daß es beim IE auf ActiveX basiert. Und selbst wenn JS nicht deaktiviert ist, ActiveX ist *so* unsicher, daß man eher mit dem Klammerbeutel gepudert sein muß, als daß man das aktiviert hat. =:-o

Und da man mittels eines unsichtbaren (I)Frames und JS eine ebensolche Funktionalität (unter Verzicht auf ActiveX!) erreichen kann, halte ich Ajax für ziemlich verzichtbar ...

hatte ich erwähnt, dass es sich hierbei um eine Applikation für Intranet handelt, die nur von unseren Kunden eingesetzt wird?
Somit ist die Sicherheit nicht gefährdet (ausser die Sysadmins können generell nicht für Sicherheit sorgen - aber das ist nicht mein Problem...).
Zudem können wir voraussetzen, was benötigt wird und was nicht. Kunden, die dies nicht möchten, können gerne die alte Variante weiterhin nutzen.

Freilich haben wir uns über diese Punkte Gedanken gemacht und sind zu dem Schluss gekommen, dass die Vorteile doch überwiegen.

liebe Grüße aus Berlin
lina-

[Cybaer]

Hi,

hatte ich erwähnt, dass es sich hierbei um eine Applikation für Intranet handelt, die nur von unseren Kunden eingesetzt wird?

Nein, aber das hättest Du tun müssen.

Kingt aber auch eher nach Extranet denn nach Intranet.

Gruß, Cybaer

[lina-]

moin Cybaer :)

hatte ich erwähnt, dass es sich hierbei um eine Applikation für Intranet handelt, die nur von unseren Kunden eingesetzt wird?

Nein, aber das hättest Du tun müssen.

Sorry - ich vergesse das immer wieder!
Für mich selber ist das ja auch sowas von klar... weshalb ich es auch immer wieder unterschlage (ist ja nicht das erste mal)...

Werd mir jetzt nen Post'it an den Moni kleben "nich vergessen zu sagen, dass es nicht fürs WWW ist" ;)

liebe Grüße aus Berlin
lina-

[Cybaer]

Hi,

weshalb ich es auch immer wieder unterschlage (ist ja nicht das erste mal)...

Ich hoffe, Du sitzt jetzt in der Ecke und schämst dich! ;-)

Gruß, Cybaer

[lina-]

moin Cybaer :)

weshalb ich es auch immer wieder unterschlage (ist ja nicht das erste mal)...

Ich hoffe, Du sitzt jetzt in der Ecke und schämst dich! ;-)

schon die ganze Nacht über konnte ich deswegen nicht schlafen ;)
*meinen Moni mit Post'its volltacker*

liebe Grüße aus Berlin
lina-

[Cybaer]

Hi,

schon die ganze Nacht über konnte ich deswegen nicht schlafen ;)
*meinen Moni mit Post'its volltacker*

Guuut! Dann fällst Du nach vorne auch ein wenig weicher, wenn Du übernächtigt vorm Monitor einnickst! ;)

Gruß, Cy-"Hoffe, Du kannst das überhaupt noch lesen"-baer

[molily]

Hallo,

Na ja, viele Browser der Generation "Netscape 4" sind sicherlich nicht mehr im Einsatz. Aber wie für alle clientseitige Techniken gilt auch bei Ajax: Abschaltbar, also nichts damit machen, was *zwingend* machbar sein muß.

Abschaltbares Ajax ist keine glückliche Formulierung. Natürlich kann man eine Parallelanwendung ohne JavaScript erstellen. Die serverseitige Logik wird dann so gestaltet, dass sowohl eine Schnittstelle in der Art eines Web Services für Ajax-Anwendungen bereitsteht, als auch eine normale HTML-Schnittstelle als klassische serverseitig-dynamische Webseite.

Bei Ajax speziell kommt noch hinzu, daß es beim IE auf ActiveX basiert.

Bitte werfe die Begriffe Ajax und XMLHttpRequest nicht durcheinander. Ajax (das Interface-Konzept) ist nicht XMLHttpRequest (eine Technik zur Hintergrund-Kommunikation mit dem Server). Und XMLHttpRequest (Einsatz von Kommunikation mit dem Server) bedeutet noch längst nicht Ajax (eine voll dynamische Webanwendung vor allem mit Ein-Seiten-Benutzerführung). Das Forum hier z.B. nutzt auch vereinzelt XMLHttpRequest, von einer Ajax-Anwendung kann man dennoch nicht sprechen.

Und da man mittels eines unsichtbaren (I)Frames und JS eine ebensolche Funktionalität (unter Verzicht auf ActiveX!) erreichen kann, halte ich Ajax für ziemlich verzichtbar ...

Ja, XMLHttpRequest ist u.U. verzichtbar - für eine Ajax-Anwendung. Allerdings ist das Senden gewisser Daten per POST oder z.B. ein HEAD-Request schwer mit iframes durchführbar.

Mathias

[Cybaer]

Hi,

Abschaltbares Ajax ist keine glückliche Formulierung.

? Hmm, das "J" steht für J(ava)Script. Mithin abschaltbar.

Natürlich kann man eine Parallelanwendung ohne JavaScript erstellen.

Ja klar. Das kann man so gut wie immer - sofern einem serverseitige Techniken zur Verfügung sehen. =:-)

Allerdings ist der Sinn von Ajax (halt wg. der Vorteile durch die "A"synchronität) ja wohl gerade, diesen "Aufwand" zu vermeiden, bzw. die damit einhergehenden "Nachteile" eben nicht zu haben.

Und daß man mit z.B. PHP "X"ML-Resourcen verarbeiten kann, ist ja auch nicht neu - nur geht das eben nicht "nebenbei".

Gruß, Cybaer

[Tim Tepaße]

Hallo Cybaer,

Abschaltbares Ajax ist keine glückliche Formulierung.
? Hmm, das "J" steht für J(ava)Script. Mithin abschaltbar.

Die Schlagwörter hier heissen wohl eher graceful degregation bzw. progressive enhancement oder auch unobtrusive scripting.

Tim

[Cybaer]

Hi,

? Hmm, das "J" steht für J(ava)Script. Mithin abschaltbar.
Die Schlagwörter hier heissen wohl eher graceful degregation bzw. progressive enhancement oder auch unobtrusive scripting.

:) Oder auf gut Deutsch: Das gute, alte, zumindest in diesem Forum auch stets propagierte Motto: "Mach dich nicht von einer clientseitigen Technik abhängig, sondern sorge bei (durchaus löblicher wenn vorteilshafter) Verwendung von selbiger für einen Fallback durch serverseitige Technik." :-)

Oder hattest Du noch etwas anderes im Auge? Denn ich sehe jetzt nicht, daß das spezifisch das Thema Ajax berührt.

Ich befürchte allerdings, daß dieses Grundmotto erneut viele Webautoren, wie bei bisher wohl noch bei jedem Hype um eine JS-basierte Technik, geflissentlich ignorieren werden ... >8->

Gruß, Cybaer

[Tim Tepaße]

Hallo,

:) Oder auf gut Deutsch: Das gute, alte, zumindest in diesem Forum auch stets propagierte Motto: "Mach dich nicht von einer clientseitigen Technik abhängig, sondern sorge bei (durchaus löblicher wenn vorteilshafter) Verwendung von selbiger für einen Fallback durch serverseitige Technik." :-)

Ja, so ungefähr. Wir meinen dasselbe. Mein Problem ist, dass ich immer noch keinen griffen deutschen Begriff für das Konzept kenne, die Grobübersetzung ist eher .. nun ja. Ich habe mal eine Zeit lang mit „Schichtenmodell“ (oder „Zwiebelprinzip“ [1]) geliebäugelt, nach dem eine Seite aus einer Reihe von Schichten besteht, die durchaus zusätzliche Funktionalität gegenüber der Basisschicht (HTML & HTTP GET & POST) bieten dürfen, aber dass die Grundfunktionalität der Basisschicht weiterhin funktionabel bleiben soll. Allerdings verleitet der Begriff Schichten einen durchaus dazu, nicht auf die Abhängigkeiten zwischen diesen zu achten. Von unten nach oben ist das kein Problem, sollte bei sauberem Entwerfen ja Normalzustand sein, von oben nach unten ist das aber eher ein Problem.

[1] Nach dem Zwiebelprinzip, nach dem man sich bei Übergangswetter kleiden soll, um so je nach der aktuelle Temperatur etwas ab- oder anlegen kann, ohne plötzlich nackt da zu stehen.

Oder hattest Du noch etwas anderes im Auge? Denn ich sehe jetzt nicht, daß das spezifisch das Thema Ajax berührt.

Doch, ich glaube schon, dass das Ajax mehr als anderes berührt, da gerade Ajax einen dazu verleiten mit dem Modell einer „Web Application“ vor dem inneren Auge zu entwickeln, anstatt erst mal Basisfunktionalität auf dem doch unterschiedlichen Modell des HTTP-Requests bereit zu stellen. Und manche - fast schon viele - „Web Applications“ haben das Merkmal, schlecht oder für den Benutzer sehr unkomfortabel mittels klassischem Request-Modell zu funktionieren.

Ein Beispiel: Mal angenommen, ich würde eine Online-Version von Kniffel zu entwickeln, bei der mehrere Spieler an verschiedenen Rechnern gegeneinander spielen könnten. Koordination zwischen den Spielern (= deren aufgerufenen Seiten) wie die Entscheidung, wer gerade an der Runde ist, das Erzeugen von Würfelergebnissen und das Verwalten der Einträge auf dem Zettel müssten natürlich serverseitig erfolgen. Im Ajax-Modell würde man ersteres mit einem im Hintergrund andauernden Request, zweiteres und dritteres mittels zielgerichteter Requests basteln, natürlich alles, ohne, dass die im Browser aufgerufene Seite neu geladen werden muss. Bei Nicht-Vorhandensein von Javascript würden streng genommen alle Nutzeraktionen mittels POST an den Server gesendet werden, ein ständiges Neuladen der aufgerufenen Webseite. Nicht gerade eine Methode, wie man spielen möchte.

Tim

[Cybaer]

Hi,

Mein Problem ist, dass ich immer noch keinen griffen deutschen Begriff für das Konzept kenne,

Abwärtskompatibilität.

OK, trifft es auch nicht zu 100%. Schließlich kann man ja sagen "was scheren mich alte Browser - soll der User doch gefälligst updaten"; ignorierend, daß sich auch aktuelle Browser, aus welchem Grund auch immer, "alt" verhalten können.

Und es impliziert ggf., daß man deswegen auf neue Technik verzichtet - was man ja gerade nicht tut und auch nicht tun will.

Am ehesten trifft es IMHO also der gute, alte, (neu-)deutsche Begriff "Fallback-Mechanismus". ;-) Oder "redundantes System".

Doch, ich glaube schon, dass das Ajax mehr als anderes berührt, da gerade Ajax einen dazu verleiten mit dem Modell einer „Web Application“ vor dem inneren Auge zu entwickeln, anstatt erst mal Basisfunktionalität auf dem doch unterschiedlichen Modell des HTTP-Requests bereit zu stellen.

Ja, schon.

Aber dieses Phänomen ist ja trotzdem nicht auf Ajax, ja nicht mal auf JS beschränkt. Man denke nur an die in der Vergangenheit (und teilweise noch) nicht unüblichen "Menüs nur in JS/Java/Flash" oder Frames, aber auch Bilder, ohne Alternativangebot

Und manche - fast schon viele - „Web Applications“ haben das Merkmal, schlecht oder für den Benutzer sehr unkomfortabel mittels klassischem Request-Modell zu funktionieren.

Wenn überhaupt.

Nicht gerade eine Methode, wie man spielen möchte.

Das ist wohl war. Nur: Die Alternative wäre, aufs Spielen ganz zu verzichten. Die Frage stellt sich doch "nur": Ist der User überhaupt bereit, die weniger komfortable Version zu nutzen, wenn er gezwungen ist, auf die "Komforttechniken" zu verzichten? Und wenn dies zu bejahen wäre: Ist der Autor auch bereit, sich diese zusätzliche Arbeit zu machen?

Hat z.B. Chräckers Stempelsite ohne JS einen Sinn? (Jetzt mal davon ausgehend, daß sie überhaupt einen "Sinn" hat. ;-)) Prinzipiell wäre es natürlich möglich, diese Site eingeschränkt auch unter Verzicht von JS zu erstellen (Stempel auswählen, Mausposition mittels grafischem Submit übermitteln, und dann auf dem Server die Position auswerten und anhand des ausgewählten Stempels und der Position eine neue Submit-Grafik erzeugen).

*Mein* "Problem" bleibt eher "ActiveX". D.h., selbst *wenn* eine Applikation nur mittels DHTML sinnvoll ist: Es ist i.d.R. doch aus Sicherheitsgründen deaktiviert/beschränkt - oder sollte es zumindest sein. Mittels (I)Frames (nach Belieben dynamisch erzeugt) kann man eben auch solcherart Web-Applikationen erstellen. POST-Requests bedingen "nur" die Verwendung von (ggf. ebenfalls dynamisch erzeugten) FORMs. Einzig die von molily erwähnten HEAD-Requests bedürfen der Mithilfe einer serverseitigen Sprache (na ja, wer's braucht), die allerdings ohnehin notwendig ist, wenn man sonst ggf. Probleme mit dem Cross-Site-Scripting bekäme.

Gruß, Cybaer

[Tim Tepaße]

Hallo Cybaer,

ich sehe, wir sind weitesgehend einer Meinung.

Am ehesten trifft es IMHO also der gute, alte, (neu-)deutsche Begriff "Fallback-Mechanismus". ;-) Oder "redundantes System".

Redundanz ist gut, damit könnte man etwas basteln.

*Mein* "Problem" bleibt eher "ActiveX". D.h., selbst *wenn* eine Applikation nur mittels DHTML sinnvoll ist: Es ist i.d.R. doch aus Sicherheitsgründen deaktiviert/beschränkt - oder sollte es zumindest sein. Mittels (I)Frames (nach Belieben dynamisch erzeugt) kann man eben auch solcherart Web-Applikationen erstellen.

Mit ein Grund, warum XMLHttpRequest, ob nur ActiveX oder direkt im Browser unterstützt, so beliebt ist, ist, dass es einen die Möglichkeit bietet, wirklich alle Features von HTTP auszunutzen, von allen HTTP Verben über Status-Codes bis hin zu Erweiterungen wie z.B. WebDAV. Die Möglichkeit, sich HTTP zu bedienen hat wirklich gefehlt. Du hast natürlich recht, dass die im IE erzwungene Nutzung von ActiveX Kopfschmerzen bereitet. Da kann man nur auf die Zukunft hoffen, der IE 7 wird wohl ein natives XMLHttpRequest Objekt enthalten, wie das IEBlog schreibt. Dazu kommen noch andere Entwicklungen, Mozilla, Opera und Apple scheinen sich in der sich noch in der Entwicklung befindlichen Spezifikation Web Applications 1.0 auf eine gemeinsame Interpretation von XMLHttpRequest zu einigen. Und das W3C ist endlich aufgewacht, hat erkannt, das DOM 3: Load & Save eher doof ist und plant in der neu gegründeten Web APIs Working Group u.a. eine „more powerful HTTP library“ - also in vier Jahren oder so. ;)

Tim

[Cybaer]

Hi,

Mit ein Grund, warum XMLHttpRequest, ob nur ActiveX oder direkt im Browser unterstützt, so beliebt ist, ist, dass es einen die Möglichkeit bietet, wirklich alle Features von HTTP auszunutzen, von allen HTTP Verben über Status-Codes bis hin zu Erweiterungen wie z.B. WebDAV.

Keine Frage. Sinnvoll ist die Technik allemal (wer hat sie doch gleich erfunden? Microsoft? >;->). Andernfalls bleibt halt nur, dieses mit Hilfe von serverseitigen Sprchen zu erreichen.

Da kann man nur auf die Zukunft hoffen, der IE 7 wird wohl ein natives XMLHttpRequest Objekt enthalten,

Wenn ich allerdings sehe, daß sogar der IE 5 noch im Einsatz ist (der 5.5 sogar nicht unbeträchtlich), bzw. wie verbreitet Win NT und 2000 immer noch sind, dann habe ich ziemliche Zweifel, daß man nach Erscheinen des 7ers bald von einer Ablösung durch selbigen sprechen können wird. >;-)

„more powerful HTTP library“ - also in vier Jahren oder so. ;)

:) Hautpsache, ich sehe so etwas noch in realer Verbreitung, bevor ich in die Rente gehe. >;->

Na ja, das Holodeck will ich auch noch erleben ... ;)

Gruß, Cybaer

[molily]

Hallo,

Und manche - fast schon viele - „Web Applications“ haben das Merkmal, schlecht oder für den Benutzer sehr unkomfortabel mittels klassischem Request-Modell zu funktionieren.

Die heilige Kuh »JavaScript immer optional« hat die Ajax-Forschung schon längst geschlachtet. Naja, zumindest als Dogma taugt diese Vorschrift angesichts Ajax nicht mehr. Es kommt viel mehr darauf an, zwischen Webanwendungen und Nicht-Webanwendungen zu unterscheiden und im Einzelfall zu unterscheiden, ob eine Zugänglichkeit ohne JavaScript überhaupt einen Sinn ergibt (Dogmen hingegen ermöglichen keinen Ermessensspielraum). Insofern kann man zurecht zum Schluss kommen, dass einige Ajax-Webanwendungen nicht abwärtskompatibel sein müssen (bzw. können).

Mathias

[molily]

Hallo,

Sehr empfehlen kann ich die prototype Library

Aaaahhh, Hilfe... der Hype um diese Bibliothek ist schlimm. Sie hat nicht einmal eine Dokumentation oder eine dokumentierte API. Geschweige denn eine Erklärung all der komplexen internen OO-Fummelei. Man denke alleine schon an die Kritik an Object.prototype.methode. Deren Implikationen sind sich JavaScript-Freaks bewusst, aber für Anfänger, die einfach eine XMLHttpRequest-Bibliothek brauchen und vielleicht ein addEvent/removeEvent, ist diese Bibliothek mit Sicherheit ungeeignet. Da googelt man lieber nach einem anderen AJAX-Framework für JavaScript.

Mathias

[at]

Hallo.

Aaaahhh, Hilfe...

[...]

Da googelt man lieber nach einem anderen AJAX-Framework für JavaScript.

In der vagen Hoffnung, dass du dabei nicht nach Hilfe rufst? Oder ist einfach jedes andere besser?
MfG, at

[molily]

Hallo,

Da googelt man lieber nach einem anderen AJAX-Framework für JavaScript.

In der vagen Hoffnung, dass du dabei nicht nach Hilfe rufst? Oder ist einfach jedes andere besser?

Ich kann keine speziell empfehlen. »Für Anfänger, die einfach eine XMLHttpRequest-Bibliothek brauchen und vielleicht ein addEvent/removeEvent« sind tatsächlich die üblichen Alternativen ausreichend. Natürlich als Einstieg, nicht als erschöpfende Allround- und Rundum-Sorglos-Bibliotheken. Ich will nicht prototype mit solchen einfachen XMLHttpRequest-Abstraktionslayern vergleichen.
prototype bietet eine Fülle von nützlichen Fähigkeiten in einer Bibliothek versammelt. Jeder, der AJAX-Anwendungen einer gewissen Komplexität entwickelt, sollte sich mit ihren Konzepten befassen. Aber wenn man völlig neu in der Materie ist und vor allem kein JavaScript-Wizard ist, gestaltet sich die Nutzung dieser Möglichkeiten als schwierig - nicht zuletzt wegen mangelhafter Dokumentation und fehlender Tutorials für die Teile von prototype, die sie von einfachen XMLHttpRequest- und addEvent-Bibliotheken unterscheiden. Andererseits »erziehen« solche umfassenden Bibliotheken zu einem klaren Programmierstil von Anfang an, denn die ganze Detailfummelei wird ausgelagert. Der Programmierer kann dadurch recht abstrakten lesbaren und wartbaren Code schreiben.
Ich für meinen Fall stehe dem umfassenden Anspruch von prototype eher skeptisch gegenüber. Ich zweifle daran, dass ein Anfänger die Bibliothek effzient nutzen kann, ohne sich über die Mechanismen unter der Haube Gedanken zu machen. Ich nehme an, dass es sinnvoller ist, selbst herumzuexperimentieren mit ersten eigenen AJAX-Anwendungen. Dann erkennt man den Vorteil einer Auslagerung und Abstraktion bestimmter Funktionalitäten sehr schnell. An dem Punkt kann man beginnen, sich mit prototype zu beschäftigen.

Mathias

[at]

Hallo.
Danke. Das war zwar auch nicht konkreter, aber zumindest sehr viel besser begründet.
MfG, at

[small-step]

Hallo lina-,

Speziell würde ich gern wissen, welche Bücher empfehlenswert sind (Vorkenntnisse in Javascript, HTML und CSS sind freilich vorhanden - ich brauch also kein Anfängerbuch).

Ehrlich gesagt halte ich hier einige gute Links schon für ausreichend.

Ebenso interessant würde ich Linktipps zu besonders guten Tutorials finden.

Das kommt immer darauf an wie Du Ajax einsetzen möchtest. In Verbindung mit ASP.Net kann ich z.B. http://www.schwarz-interactive.de/ sehr empfehlen. An Ajax.Net Pro führt unter .Net kaum ein Weg vorbei, das ist eine enorme Arbeitserleichterung.

Ein darauf aufbauendes, sehr gutes Tutorial findest Du hier http://www.developerfusion.co.uk/show/4704/1/. Allerdings bezieht es sich noch auf die letzte Version - Ajax.Net, nicht Ajax.Net Pro - die Unterschiede sind jedoch ziemlich gering und recht schnell erfasst.

Das Projekt, das mit Ajax neu aufgesetzt werden soll ist eine relativ große Webanwendung, die sehr Guilastig ist. Denke da ist das neue Buzzword "Ajax" genau das richtige? Oder?

Wenn viel Interaktion mit dem Client gefragt ist auf jeden Fall. Die Nutzung von Ajax sollte allerdings nicht übertrieben werden. Es gibt Fälle in denen ein simples Formular völlig ausreichend ist.

Gruß,
small-step

[lina-]

moin small-step :)

Erstmal vielen Dank für die Tipps.

Speziell würde ich gern wissen, welche Bücher empfehlenswert sind (Vorkenntnisse in Javascript, HTML und CSS sind freilich vorhanden - ich brauch also kein Anfängerbuch).
Ehrlich gesagt halte ich hier einige gute Links schon für ausreichend.

Hast du da welche parat?

Ebenso interessant würde ich Linktipps zu besonders guten Tutorials finden.
Das kommt immer darauf an wie Du Ajax einsetzen möchtest. In Verbindung mit ASP.Net kann ich z.B. http://www.schwarz-interactive.de/ sehr empfehlen. An Ajax.Net Pro führt unter .Net kaum ein Weg vorbei, das ist eine enorme Arbeitserleichterung.

Da wir mit OpenSource-Dingen arbeiten kommt Microsoft nicht in Frage - daher auch kein ASP. Bisher haben wir das ganze mit Struts gelöst.
Gibt es wohl noch andere Frameworks (so ganz ohne könnte das mühsam werden...)?

Das Projekt, das mit Ajax neu aufgesetzt werden soll ist eine relativ große Webanwendung, die sehr Guilastig ist. Denke da ist das neue Buzzword "Ajax" genau das richtige? Oder?
Wenn viel Interaktion mit dem Client gefragt ist auf jeden Fall. Die Nutzung von Ajax sollte allerdings nicht übertrieben werden. Es gibt Fälle in denen ein simples Formular völlig ausreichend ist.

Das ist schon klar... ich werde mich wohl an den Grundsatz halte, dass das was bisher mit Formularen gelöst wurde, weiterhin beibehalten wird (Konfigurationsseiten etc).
Aber das gesamte Geraffel mit den Ansichten, Umschalten der Ansichten, auszuführende Aktionen und daraus resultierende neue Ansichten - das wird wohl alles besser werden :)

liebe Grüße aus Berlin
lina-

[small-step]

Hallo lina-,

Ehrlich gesagt halte ich hier einige gute Links schon für ausreichend.
Hast du da welche parat?

Außer meiner gigantischen, M$-spezifischen... nein ;-)

Da wir mit OpenSource-Dingen arbeiten kommt Microsoft nicht in Frage - daher auch kein ASP. Bisher haben wir das ganze mit Struts gelöst.
Gibt es wohl noch andere Frameworks (so ganz ohne könnte das mühsam werden...)?

Ich weiß, dass es zumindest für PHP mehrere Ansätze gibt. Da bin ich aber nur zufällig drüber gestolpert. Aber Google könnte helfen.

Das ist schon klar... ich werde mich wohl an den Grundsatz halte, dass das was bisher mit Formularen gelöst wurde, weiterhin beibehalten wird (Konfigurationsseiten etc).

Gerade sowas ist eigentlich recht nett mit Ajax zu lösen finde ich. Aber ein Kontaktformular oder was auch immer muss ja nicht wirklich derart überladen werden.

Aber das gesamte Geraffel mit den Ansichten, Umschalten der Ansichten, auszuführende Aktionen und daraus resultierende neue Ansichten - das wird wohl alles besser werden :)

Ich wünsche dabei viel Spaß :-) Meiner Erfahrung nach war gerade der Einstieg in Ajax schnell und einfach. Allerdings hab ich mit .Net eben auch einen ziemlich mächtigen Wrapper zur Hand. Ich ärger mich momentan am meisten mit dem JavaScript-Kram rum, ist nicht wirklich meine Leidenschaft...

Gruß,
small-step

[lina-]

moin small-step :)

Das ist schon klar... ich werde mich wohl an den Grundsatz halte, dass das was bisher mit Formularen gelöst wurde, weiterhin beibehalten wird (Konfigurationsseiten etc).
Gerade sowas ist eigentlich recht nett mit Ajax zu lösen finde ich. Aber ein Kontaktformular oder was auch immer muss ja nicht wirklich derart überladen werden.

hmm... genauer hab ich mir das noch nicht angeschaut - aber wir werden sehen, was dabei herauskommt :)

Aber das gesamte Geraffel mit den Ansichten, Umschalten der Ansichten, auszuführende Aktionen und daraus resultierende neue Ansichten - das wird wohl alles besser werden :)
Ich wünsche dabei viel Spaß :-) Meiner Erfahrung nach war gerade der Einstieg in Ajax schnell und einfach. Allerdings hab ich mit .Net eben auch einen ziemlich mächtigen Wrapper zur Hand. Ich ärger mich momentan am meisten mit dem JavaScript-Kram rum, ist nicht wirklich meine Leidenschaft...

Ich denke es wird sich für mich auch was finden, hab ja von FraFu schon nen klasse Link bekommen.
Um das Javascript-Zeug mach ich mir weniger Sorgen - damit hab ich mich bisher auch schon rumgeplagt... so viel schlimmer kanns nicht werden ;)

liebe Grüße aus Berlin
lina-

[Andreas Dölling]

Hallo,

hier ein paar Links, die ich persönlich sehr hilfreich fand:
http://del.icio.us/tag/xmlhttprequest
http://del.icio.us/tag/ajax
http://www.xulplanet.com/references/objref/XMLHttpRequest.html

Aus meiner bisherigen Erfahrung heraus muß ich aber sagen, daß ich erst in zwei Fällen Ajax in tatsächlich sinnvoller Weise eingesetzt habe. Und in beiden Fällen sind es eher recht simple Scripte.
Ansonsten sind wir hier bei allen anderen Diskussionen darüber, ob nun für ein bestimmtes Problem Ajax zum Einsatz kommen sollte, immer zu dem Schluß gekommen, daß es keinerlei Gewinn gegenüber einem "herkömmlichen" formular- oder linkbasierten Ansatz gebracht hätte. Eher im Gegenteil.

Aber das muß man natürlich von Fall zu Fall unterscheiden.

Beherzigen sollte man aber bei seiner Entscheidung auf jeden Fall die Hinweise unter http://www.baekdal.com/articles/Usability/XMLHttpRequest-guidelines/.

Ciao,
Andreas

[lina-]

moin Andreas :)

hier ein paar Links, die ich persönlich sehr hilfreich fand:
http://del.icio.us/tag/xmlhttprequest
http://del.icio.us/tag/ajax
http://www.xulplanet.com/references/objref/XMLHttpRequest.html

Vielen vielen Dank!

Aber das muß man natürlich von Fall zu Fall unterscheiden.

Beherzigen sollte man aber bei seiner Entscheidung auf jeden Fall die Hinweise unter http://www.baekdal.com/articles/Usability/XMLHttpRequest-guidelines/.

Hab mir das durchgelesen und habe ein eindeutiges "Pro" für mich herausgelesen :) Ich freu mich schon richtig drauf, die ersten Spielerein damit zu machen.

liebe Grüße aus Berlin
lina-