Vollständigen Link anzeigen: javarea.de Forum > Talk Talk > Wer ist fit in Ajax ?
| geschrieben von Klaush am 04.10.2006 - 21:48 |
| Hat jemand Erfahrungen mit Ajax gemacht und kann darüber berichten oder gibt es gar schon einige unter euch die Ajax im Einsatz haben? |
| geschrieben von Patrick am 04.10.2006 - 22:04 |
| Hallo klaus, Ajax soll bei uns in den nächsten Monaten im neuen Intranet Auftritt verwendet werden. Das größte Problem was sich bisher herausstellte ist, dass das XMLRequest...-Objekt immer auf den Browsercache vom IE zugreift, auch wenn es eigentlich die Sachen direkt von Server holen sollte... (Weiss den genauen Objektnamen nicht). Ansonsten bringt Ajax viele Vorteile, vor allem was die Geschwindigkeit angeht. Weitere Details kann ich dir in den nächsten Wochen liefern. Derzeit untersuchen wir, welche Probleme es noch bei Ajax gibt, die eine Benutzung im neuen Intranetauftritt stoppen könnten. mfG, Patrick |
| geschrieben von Micha am 04.10.2006 - 22:20 |
| Hallo, der LeagueEditor JS nutzt seit März 2005 dieses JavaScript Objekt. Zuvor habe ich einen Umweg über ein unsichtbares (verstecktes) iFrame und innerHTML genutzt. Eine eigene Rubrik finde ich maßlos übertrieben, da es sich nur um ein einzelnes Objekt handelt. Für das Window-Objekt würde auch keiner auf die Idee kommen, es auszuklammern, oder? Canvas ist ebefalls eine solche Sache, die derzeit einen Hyp hat... Ob ich fit bin? Sicher nicht aber für meine Anwendungen wie zB auch ein Widget für meinen Atom-Feed reicht es aus. In der Regel hat diese Technik ja am gesamten Script nur einen geringen Anteil. Die eigentliche Dynamik bringt ja die Anwendung bzw. Ausnutzung der Möglichkeiten, die JavaScript mitbringt. Nachtrag Ich finde die Antwort schlecht gewählt: "NEIN muss nicht sein, findet kaum Anwendung" Es müsste lauten: "NEIN muss nicht sein, da es sich um JavaScript handelt und es dafür einen gut besuchten Bereich gibt". oder/und: "NEIN, findet kaum Anwendung" LG Micha |
| geschrieben von Danny am 04.10.2006 - 22:27 |
| Hallo Klaus, der Thread trifft den Nagel gerade auf den Kopf, denn ich habe mir grade die Video2Brain DVD über Ajax angeschaut. Ich habe bisher Ajax in ein oder zwei kleineren, eher Testprojekten eingesetzt, habe mich aber bisher nur recht oberflächlich mit der Materie beschäftigt. Das Video, welches ich mir eben teilweise angeschaut habe, hat mich dazu bewogen Teile meines aktuellen Projektes nocheinmal neu aufzugreifen und noch mehr mit Ajax zu versehen. Das Video hat unteranderem ein Framework namens prototype ( http://prototype.conio.net/ ) vorgestellt. Ich finde es ist für Interessierte ein Blick wert. @ Patrick Wenn ich dich richtig verstanden habe, trat der von dir beschriebene Fehler ebenso bei mir auf, leider hab ich bisher keine Lösung gefunden, wenn du also zu einem Ergebnis kommst wär ich über jede Antwort dankbar. Der Mozilla/Firefox macht das wie eigentlich gewünscht, mir ist es beim Opera aufgefallen der scheinbar in der Beziehung wie der IE handelt... @ Fragestellung Ich bin eigentlich für ein solches Forum, obwohl sich bisher die Quantität der Fragen über Ajax in Grenzen gehalten haben, ist es ein Versuch wert. Wenn es nichts wird, kann man ja bisher aufgekommene Beiträge in die Javascript ecke des Forums vershcieben... Bye Danny |
| geschrieben von Patrick am 05.10.2006 - 10:32 | ||||
Beim Mozilla/ Firefox tritt das Problem nicht auf, da dort die Cache-Verarbeitung eine andere ist. Beim Opera kenne ich diese nicht, glaube aber, dass diese auch anders ist als beim Internet Explorer. Es handelt sich derzeit um ein Problem, welches mit Ajax nicht umgangen werden kann sondern im Internet Explorer gefixt werden muss. Ob dieser Fehler beim IE 7 auch auftritt kann ich leider nicht sagen. Kurz gesagt: Derzeit gibt es keine Möglichkeit, dieses Problem zu umgehen, ausser man benutzt einen anderen Browser. Bei uns in der Firma ist dieses leider nicht möglich, da viele Programme auf den Internet Explorer abgestimmt sind, was leider nicht kurzfristig zu ändern geht und auch nicht gewünscht ist! Sobald ich weitere Infos zu diesem Problem bekomme, melde ich mich wieder.... Zum eigenen Forum: Meiner Meinung nach muss das nicht sein, da es sich um JavaScript und XML handelt, wozu wir Foren haben. Falls sich die Fragen häufen, kann man in Zukunft über ein extra Forum nachdenken, derzeit sehe ich keinen Bedarf |
| geschrieben von Klaush am 05.10.2006 - 11:22 | ||||
Das Suchen nach speziellen Ajax-Schnipsel wäre dann unter Umständen leichter. Muss mich wieder mehr mit JS beschäftigen. Ich bin etwas eingerostet, da ich aus der Webwelt mehr zur objektorientierten Sprachen abgewandert bin. Interessant finde ich wie man Ajax mit PHP und MySQL verbindet, hier fallen mir gleich jede Menge neuer Ideen ein die ich verwirklichen würde. |
| geschrieben von Klaush am 05.10.2006 - 13:45 |
| Ich habe mir mal etwas Zeit genommen und ein Tut über Ajax gelesen. Das erste Scriptchen in Verbindung mit PHP und Oracle habe ich auch schon fertig ..... bin ehrlich gesagt begeistert. Ich spiel mit dem Gedanken auch hier im Forum Ajax einzusetzen. Dann habe ich noch etwas gefunden  :Vorteile * Seiteninhalte können durch neue Daten vom Server geändert werden, ohne dass die Seite komplett neu geladen werden muss. Damit wird die Serverlast verringert. Änderungen werden schneller sichtbar, die User bekommen schneller Feedback. Das steigert die Usability. Zudem bleibt beim Nachladen der Daten der aktuelle Zustand erhalten (Position des Cursors, von Elementen, usw.). Das vereinfacht die Programmierung. * Es können Oberflächen geschaffen werden, die Desktop-Applikationen ähneln. Damit können zunehmend mehr Aufgaben über Web-Applikationen erledigt werden. Das kommt der zunehmenden mobilen Nutzung zugute. Die Stärke des Webs, immer und überall verfügbar zu sein, wird damit besser ausgenutzt. Nachteile / Probleme / Grenzen * AJAX setzt voraus, dass JavaScript aktiviert ist. Damit scheidet die Verwendung von AJAX für normale Web-Seiten, die auch ohne Javascript benutzbar sein müssen, weitgehend aus. Vorrangiges Einsatzgebiet für AJAX sind Web-Seiten mit Applikationscharakter, z.B. in Intranets. Auf normalen Web-Seiten sollte AJAX derzeit nur als optionales Goodie verwendet werden. * AJAX setzt beim Internet Explorer voraus, dass die Ausführung von ActiveX-Objekten erlaubt ist. Aus Sicherheitsgründen haben manche Benutzer/innen dieses abgeschaltet. Anmerkung: Der kommende IE 7 soll eine native Unterstützung von XMLHTTPRequest erhalten. * Die Verwendung von AJAX kann zu einem deutlich höheren Aufwand für die Client- und Serverseitige Programmierung und damit auch einen finanziellen Mehraufwand führen. Dort, wo AJAX zum Einsatz kommt, wird häufig zumindest für eine Übergangszeit auch noch eine Fallback-Lösung implementiert werden müssen, damit wichtige Teilbereiche einer Site, z.B. Formulare, auch ohne AJAX verwendet werden können. Das wird zu einem deutlichen Mehraufwand führen. * Die Trennung von Struktur (XHTML) und Layout (CSS) wird möglicherweise wieder aufgehoben. Die Entwicklung im Bereich Web-Frontends geht hin zu einem semantischen Web. D.h., nicht das Layout, sondern die strukturierte Darstellung der Daten in XML-Form ist vorrangig relevant. Das Layout wird weitgehend getrennt davon, je nach Ausgabemedium über CSS oder XSLT erzeugt. DHTML bedeutet das Zusammenspiel von Javascript und CSS. Die Gefahr ist also, dass hier diese sinnvolle Trennung nicht beibehalten wird. * Interfaces werden möglicherweise unbedienbar, da sie neue Elemente enthalten, die die User nicht erwarten, oder Bedienelemente nicht wie erwartet funktionieren (z.B. kein Submit-Button, Back-Button funktioniert nicht). Mittlerweile haben sich bestimmte Abläufe und Quasi-Standards bei der Bedienung von Web-Seiten durchgesetzt. Formulare werden über den Submit-Button abgeschickt, Navigationen befinden sich innerhalb bestimmter Bereiche der Web-Seite, u.ä. Wer heute etwas über einen Online-Shop bestellt wird feststellen, dass die meisten Shops relativ ähnlich aufgebaut und deshalb einfach zu benutzen sind. Wenn jetzt bestimmte Elemente, z.B. Formulare, nicht mehr so wie gewohnt funktionieren, kann das mehr zur Verwirrung beitragen, als das es den User/innen nutzt. * Seiten, die mittels JavaScript/AJAX verändert worden sind, können nicht einfach ausgedruckt werden, da der Browser derzeit die Seite so ausdruckt, wie sie ursprünglich vom Server geladen worden ist. * AJAX-Anwendungen unterliegen den Beschränkungen des zustandlosen HTTP-Protokolls. Eine dauerhafte Verbindung zum Server ist nicht möglich, d.h. der AJAX-Client sich nicht beim Server registrieren um von ihm über bestimmte Ereignisse informiert zu werden, auf die der AJAX-Client dann reagieren kann. Stattdessen muss er regelmäßig Anfragen an den Server schicken, um zu klären, ob ein neues Ereignis eingetreten ist. Das kann den Vorteil von AJAX, die Serverlast zu verringern, in das Gegenteil umkehren. * DHTML / AJAX ist nicht vereinbar mit Barrierefreiheit. Seiten, die barrierefrei sein sollen, müssen immer auch ohne Javascript bedienbar sein. * Der sozusagen hinter dem Rücken der User/innen durchgeführte Datenaustausch kann zu Verunsicherungen führen, da die User/innen nicht mehr die Kontrolle über ihre Daten haben (insbesondere bei Formularen, wo die Eingaben normalerweise erst nach Betätigen des 'Submit'-Buttons gesendet werden). * Nach wie vor sind zahlreiche Methoden und Verhaltensweisen in unterschiedlichen Browsern verschieden oder auch gar nicht implementiert. Bestimmte Methoden funktionieren nicht oder zumindest nicht wie erwartet. Das bedeutet, dass umfangreiche Tests in verschiedenen Browsern nötig sind. Nicht selten nimmt der Aufwand dafür, bestimmte Verhaltensweisen, die nicht oder fehlerhaft im Browser implementiert sind, mittels Javascript nachzubilden, einen wesentlichen Teil des Gesamtaufwands bei der Programmierung ein. * Die Interaktion zwischen Desktop-Anwendungen und Web-Anwendungen ist kaum möglich, da der direkte Zugriff auf die Zwischenablage fehlt. Der fehlende Zugriff auf die Zwischenablage, aus Sicherheitsgründen unabdingbar, stellt eine Grenze für Web-Applikationen dar ebenso wie die Tatsache, dass mittels Javascript keine Grafiken manipuliert oder erstellt werden können. Auch das Zeichnen von Elementen der Bedienoberfläche ist nicht möglich. Die Kontrolle über die Bedienoberfläche behält letztlich der Browser, dessen Verhaltensweisen über vorgegebene Methoden und Eventhandler beeinflußt werden kann. An die Möglichkeiten normaler Programmiersprachen reicht Javascript bei weitem nicht heran. |
| geschrieben von okley am 05.10.2006 - 14:14 |
| Ich hab mich auch noch nicht intensiv damit auseinandergesetzt. Aber doch schon einige Problemstellungen angeschaut und auch lösen können. Da AJAX eine Javascript basierende Technik ist, sehe ich da kein Bedarf ein neues Forum einzurichten. Nun zu den Negativ Punkten von Klaush, ich möchte da einiges entkräften, da ich doch ein Befürworter von sinnvollem Ajax Einsatz bin ;) Punk 1 bringts auf den Punkt ;). Allerdings habe ich mit RC1 IE7 bisher kein Erfolg diese http://www.formassembly.com/time-tracker/ Ajax-Seite anzuzeigen ... Mit http://www.iloveim.com/ funktioniert es allerdings. Daraus schliesse ich das ActiveX nicht zwingend benötigt wird... oder sehe ich was falsch? Zur Zeit gibt es sehr viele Ajax-Frameworks, einzelne davon kann man sogar nutzen ;). Daher denk ich, dass der Aufwand nicht allzuviel grösser sein wird. Mit dem Atlas-Framework von Microsoft ist die Ajaxtechnologie auch in professionellem OOP Umfeld einfach zu nutzen. Mehr Frameworks -> http://www.ajaxprojects.com/ Das Verhalten der Steuerelemente mag sich etwas ändern, dafür sieht der Benutzer schnell, dass mehr Comfort da ist. Wenn die Benutzerführung stimmt, wird er auch nicht verwirrt sein, denke ich. Für das Navigationsproblem Zurück, Vorwärts mit Ajax gibt es bereits eine Lösung... -> http://www.contentwithstyle.co.uk/A....-ajax-apps @Micha Damit die Werbung auch ja nicht zu kurz kommt  Bzw. fände ich es noch toll wenn man während dem Editieren genauso alle Beiträge sieht, wie beim erstellen einer Antwort. |
| geschrieben von Matneu am 05.10.2006 - 15:58 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Da ich gerade mit Ruby on Rails angefangen habe bin ich praktisch nicht an AJAX vorbei gekommen, weil es einem dort sehr einfach gemacht wird, AJAX zu nutzen. Formulare werden durch verändern einer einzigen Zeile komplett AJAX-fertig gemacht, Links ebenso. Ich nutze es also SEHR viel, allerdings nur für ein im Intranet laufenden System mit einem festen Rechner- und Nutzerpool. Ich kann also davon ausgehen, dass alle Javascript aktiviert haben. Screenreader-Nutzer gibt es nicht, obwohl das kein Problem wäre, die Seite komplett barrierefrei, sprich auch ohne Javascript nutzbar zu machen. Bei RoR hat man allerdings den Vorteil, dass man auf vorgefertigte (und hoffentlich ausgiebig getestete) AJAX-Funktionen zurückgreifen kann. Man schreibt also keine Zeile Javascript selbst und muss sich nicht um die Browserkompatibilität kümmern. Unter Opera, FF, IE (Windows, Linux und teilweise sogar MAX) und Safari (nur Mac) lief bisher alles problemlos. Bei den Vor- bzw. Nachteilen ist mir allerdings einiges aufgefallen:
Uneingeschränkte Zustimmung
Hat aber nichts mit AJAX zu tun, das trifft genau so für andere Javascripte zu.
Über den IE brauchen wir glaube ich nicht zu diskutieren, bleiben wir lieber bei Browsern, die den Namen auch verdienen :-\
Seitdem ich RoR kenne lache ich über solche Aussagen  Schreibt man hingegen alles selbst stimmt das natürlich absolut, ist aber für den Auftragnehmer eher als Vorteil zu werten ;)
Absolut!
Absolut! Gerade die Sache mit den Zurück-Button ist sehr sehr gewöhnungsbedürftig. Und das Speichern von Lesezeichen muss man - z. B. durch einen extra erzeugten Link - explizit ermöglichen.
Stimmt nicht. Gerade getestet: Zumindest Opera und FF drucken auch die per AJAX eingeblendeten DIVs mit aus.
Diese dauerhafte Verbindung ist auch mit reinem HTML nicht möglich. Dort müsste - sollte sich irgendwas ändern - alles neu geladen werden. Demzufolge verringert AJAX die Serverlast sehr wohl. In welchem Fall AJAX nun die Serverlast vergrössert verstehe und sehe ich auch nicht.
Und warum ist AJAX nun nicht vereinbar mit Barrierefreiheit? Der Autor widerspricht sich gerade selbst.
Das hat nichts mit AJAX zu tun, das kann man auch mit Javascript schaffen.
Nicht mit RoR bzw. fertigen AJAX-Frameworks, die es sicherlich auch für PHP etc. gibt.
Natürlich nicht! Das darf auch nicht sein. Spätestens nach diesem angeblichen "Nachteil" frage ich mich, wer der Autor dieses Textes war. Kannte der sich überhaupt mit der Materie aus? Erscheint mir immer weniger der Fall zu sein. Ach so, zum Thema "weiteres Unterforum" habe ich mit "Nein" abgestimmt, weil AJAX ja eigentlich nur ein winziger Teil von Javascript ist. Was an echten AJAX-Fragen kommen könnte wäre einzig "Es werden bei mir unter XY keine Daten gesendet / empfangen, was mache ich falsch". Alles andere (Auswertung, Anzeige etc.) gehört genau genommen nicht mehr zu AJAX. So far... Matthias |
| geschrieben von Martin am 05.10.2006 - 19:25 |
| Ave, Ajax, schön und gut. Es gibt einige wirklich interessante Einsatzgebiete für diese Technik aber wie hier schon mehrfach erwähnt hat Ajax auch seine Grenzen. So zum Beispiel ist der Programmieraufwand bedingt durch das Ajax-Framework ungleich größer als frühere Lösungen. Dazu kommt, Programmierfehler sind ungleich schwerer zu lokalisieren. Und je komplexer der Auftritt/Anfragen um so spezialisierter muss das Ajax arbeiten. Denn jeder Ajax Request lässt sich nur in zwei Arten "empfangen", als responceText (reine Textform) oder responceXML (XML Baum). Egal welche Art man einsetzt jede Form benötigt eine Art post-processing (Nachbearbeitung) per Javascript. Und genau hier fängt es wieder an schwierig und aufwändig zu werden. mfg martin |
| geschrieben von Matneu am 05.10.2006 - 19:58 | ||||||||||||
Ich kenne mich mit den PHP-AJAX-Frameworks nicht aus aber wenn ich von Ruby ausgehe ist der Aufwand lächerlich gering gegenüber der Alternative, AJAX nicht zu nutzen:
Mit :update legt man fest, in welches Element der Inhalt reingeladen werden soll, :url gibt eben den Controller und die Action (also letztlich die Seite, die geladen werden soll) an und :complete sagt, was passieren soll, wenn die Daten vollständig geladen wurden. Das Gegenstück (ohne AJAX) sähe folgendermassen aus:
So gross ist der Unterschied also nicht. Und ich kann mir nicht vorstellen, dass PHP-Frameworks da wesentlich komplizierter sind. Views / Templates muss man für beide Varianten bauen. Ob ich nun noch das Layout aussendrum (Menü etc.) anzeigen lasse oder nicht ist nur Einstellungssache, macht aber kaum Unterschied. So far... Matthias |
arams => {:context => | geschrieben von nerosepp am 17.10.2006 - 14:36 | ||||
... und schon holt er die Daten vom Server! ansonsten find ich Ajax ( XML Datentunnel ) super , wir verwenden es schon seit jahren in unserer Firma. |
| geschrieben von Micha am 19.10.2006 - 07:32 | ||||
| Hi, kannst Du mir mal bitte sagen, wo Ihr den Zeitwert später verarbeitet? Danke! Auas Deinem Code konnte ich entnehmen, das Ihr dazu eine Variable X
verwendet. Das mache ich bei ähnlichen Sachen auch um den Browser zu animieren, die Seite neu zu holen aber hier konnte ich es noch nicht verbauen. Wo nutzt Du X dann im weiteren Script oder reicht die einfache deklaration? Micha |
| geschrieben von Micha am 19.10.2006 - 16:35 |
| Hi, okay, ich habe wohl zu kompliziert gedacht :/ Habs hinbekommen, in den man es simpel an den URI hängt... Danke Micha |