AJAX installieren?

[MatzeLoCal]

LoCal,
das Ziel von Ajax ist es, eine Webseite mehr wie eine richtige Desktop-App wirken zu lassen. Genau das erreicht man mit einem entsprechend geschriebenen Applet auch. Ajax ist sowohl im Hinblick auf potentiell neue Anwendungsmöglichkeiten als auch auf eingesetzte Technik nichts besonderes oder neues.

Ich weiss, ich wiederhole mich, aber AJAX und Applet sind grundlegend verschiedene Ansätze. Und damit das ganze mal deutlicher wird erkläre ich das mal

Ein Applet ist im Prinzip nichts anderes, als ein eigenständiges Programm, das auf dem Client-Rechner läuft. Sämtliche Logik wird auf dem Client ausgeführt ( zur Ausnahme von der Regel komme ich gleich). Desweiteren müssen sämtliche Bibliotheken bzw Classen, die vom Applet benötigt werden, bei jedem Ladevorgang des Applets mit überspielt werden. Und wie gesagt, sämtliche Logik findet normalerweise im Applet/beim Client statt. Die Ausnahme wäre, dass das Applet per definiertem Protokol mit dem Server kommuniziert und entsprechende Logiken dort abgebildet werden. So kann z.B. vermieden werden, dass das Applet direkt via JDBC auf eine Datenbank zugreift. Allerdings müssen diese Wege dann auch gesichert werden, aber das ist ein anderes Thema.

Bei AJAX gibt es nur den Browser zur Darstellung, sämtliche Logik findet auf dem Server statt. Die Kommunikation zwischen Client und Server beschränkt sich auf ein Minimum. Es werden nur die Veränderungen kommuniziert und da die Darstellung über einen Webserver stattfindet sind die Anforderungen an den Client entsprechend gering.
Bei uns sieht das ganze z.B. so aus. Der äussere Webserver dient nur zur Kommunikation mit dem Client. Kommt eine Anfrage werden mittels JavaMessageService (bzw einer aufgebohrten Version davon!) die relevanten Daten an den internen Server geschickt. Dort findet die gesamte Logik und Datenbank-kommunikation statt. Danach wird das ganze wieder an den Webserver geschickt, der dann die Veränderungen an den Client schickt.

 

[MacMark]

Dann setzt Ihr Ajax nicht typisch ein, denn der Clou daran ist die Logik, die per Javascript auf Clientseite verwendet wird.

 

[Nogger]

Es mag sein, daß jemand mal behauptet hat, AJAX diene dazu Businesslogik auf die Clientseite zu verlagern. Aber eine Mindermeinung ist nicht relevant.

Natürlich gibt es Logik auf dem Client, der soll ja die Darstellung ändern.

Beispiel Warenkorb. Ohne Seitenwechsel läuft ab, daß ein Benutzer ein Produkt bestellt. Javascript schickt "Hinzufügen von 2 x Produkt A" an den Server, der Antwortet: "Warenkorb besteht aus: (...), Endpreis = x, Versandkosten entfallen" und die Logik auf dem Client aktualisiert die Darstellung des Warenkorbs. (Oder der Server schickt direkt ein fertiges Stück HTML Code, daß die aktuelle Darstellung des Warenkorbs ersetzt)

DAS ist eine prototypische AJAX Nutzung. Die findest du so auch in GMail oder Google Maps (auch wenn letzteres technisch über versteckte IFrames läuft). Die findest du hier im Forum, wenn du einen Beitrag einstellst. Da wird auch nicht im Client entschieden, ob du überhaupt die Rechte besitzt einen Beitrag einzustellen und der Server stellt den nicht rein, nur weil der Client es so anfordert.

Die Businesslogik ist und bleibt auf dem Server. Alles andere wäre alleine schon aus Sicherheitsgründen fatal. Es sind stinknormale POST und GET Anfragen, die ausgelöst werden. Und Verschlüsseln ist auch nicht drin, weil der Schlüssel nicht geschützt werden kann.

 

[MacMark]

Ja Eyecandy, der ohne JavaScript nicht geht. Überflüssiger Schnickschnack. Ich halte nichts von diesem Ajax-Hype. Neuer Name für alte Techniken, von denen ich JavaScript nicht gut finde - Stichworte Barrierefreiheit und Sicherheit.

 

[Herr Sin]

Kannst ja mal in der AJAX-Community umschauen. Und hier kommst du direkt zum "AJAX Tutorials mit Code Besispielen"-Thread.

Vielleicht kommst da etwas weiter.

 

[Nogger]

Es gibt Leute, die frieren gerne morgens, bis der Motor warm genug ist um den Innenraum anzuwärmen. Und es git Leute, die haben eine Standheizung. Jeder wie er mag.

Und deine Behauptungen werden durch Wiederholung auch nicht wahrer.

 

[thumax]

Es gibt auch Leute, die garkein Auto haben und bei denen trotzdem 'ne ADAC-Zeitschrift auf dem Klo liegt...

 

[MacMark]

Mmh, da steht genau das, was ich sage:

DHTML / AJAX ist nicht vereinbar mit Barrierefreiheit. Seiten, die barrierefrei sein sollen, müssen immer auch ohne Javascript bedienbar sein.

http://www.get-the-code.de/code/javascript/ajax/ajax-benefits-problems.htm

 

[Hilarious]

MacMark, Du hast ein seltsames Konzept, rücksichtvoll zu anderen zu sein. Ist das Thema »AJAX installieren« nicht schon beantwortet?

 

[MacMark]

MacMark, Du hast ein seltsames Konzept, rücksichtvoll zu anderen zu sein. Ist das Thema »AJAX installieren« nicht schon beantwortet?

stk hatte in einem anderen Thread einen Querverweis auf seine, ähem, Beleidigung hier gesetzt, daher weise ich auch hier nach, wer richtig liegt.

 

[Hilarious]

stk hatte in einem anderen Thread einen Querverweis auf seine, ähem, Beleidigung hier gesetzt, daher weise ich auch hier nach, wer richtig liegt.

Ja, ist gut. Schreib ihm eine persönliche Mail oder ruf ihn an. Das ewige Klarstellen nervt.

 

[MacMark]

Ja, ist gut. Schreib ihm eine persönliche Mail oder ruf ihn an. Das ewige Klarstellen nervt.

Wenn er mich in einem öffentlichen Forum beleidigt, ist es durchaus legitim, ihm dort auch öffentlich zu antworten. Wenn dich das nervt, leg dir eine Elefantenhaut zu

 

[xenxox]

Wenn Du Ajax für eine barrierefreie Seite einsetzen willst, dann mußt Du alles doppelt entwickeln: Einmal mit Ajax und einmal ohne. Das ist absurd.

Nein dass muss mein nicht und selbst wenn ist es nicht absurd. Wenn man die Technik so implementiert dass sie nur eine optionale Ergänzung darstellt benötigt man keine zweite Implementierung als Fallback.

Ja Eyecandy, der ohne JavaScript nicht geht.

Es bleibt ja jedem überlassen wie er es nutzt, dein Horizont scheint bei Eyecandy aufzuhören wobei man doch mit AJAX bzw. den Zugrundelegungen Technologien sehr sinnvolle Dinge machen kann.

Stichworte Barrierefreiheit und Sicherheit.

Kannst du auch etwas anderes als irgendwelche Buzzwords ablassen?

Das einzige Problem mit AJAX ist dass es auf den XMLHTTPRequest aufsetzt und der redmonsche Browser dies nach wie vor als ActiveX Objekt implementiert hat. Aber auch editable Iframes sind afaik beim IE über ActiveX realisiert und das ist kein grund darauf zu verzichten. Es muss halt eine Ergänzung darstellen die ohne spezielle Fallbacklösung genutzt werden kann.

Aber das ist ja möglich - nun beim editable IFrame muss man alternativen schaffen - aber dass muss man sowieso das Mozilla und Opera das ganze anders implementiert haben - über Safari will ich mal gar nicht sprechen.

 

[stk]

Moin,

Nur um mal einen ganz anderen Gout reinzubringen. Auf A-List-Apart wurde heute morgen ein JS-Lösung vorgestellt, die Textvergrößerung (ein klassisches Element der Barrierefreiheit) erkennt und verhindert das ich überlappende (sprich: unleserliche) Texte ergeben:

http://www.alistapart.com/articles/fontresizing

Auch wenn das nicht explizit unter "Barrierefreiheit" gefeatured wurde, so ist durch den Zugewinn an Usability genau diese entstanden.

Gruß Stefan

 

[MacMark]

der Faktor,
deine "optionale Ergänzung" ist dann jedoch nicht barrierefrei.

Schon allein anhand deines Postings kann man doch sehen, daß Ajax dir einen Haufen Probleme bzgl. funktionaler Natur und Sicherheit beschert.

Apropos Buzzword: Barrierefreiheit ist im Gegensatz zu Ajax keines. Außer dem XmlHttpRequest aus dem Jahre 2001 bietet Ajax nichts Neues, wenn man bei 2001 noch von "neu" sprechen kann.

 

[MacMark]

Moin,

Nur um mal einen ganz anderen Gout reinzubringen. Auf A-List-Apart wurde heute morgen ein JS-Lösung vorgestellt, die Textvergrößerung (ein klassisches Element der Barrierefreiheit) erkennt und verhindert das ich überlappende (sprich: unleserliche) Texte ergeben:

http://www.alistapart.com/articles/fontresizing

Auch wenn das nicht explizit unter "Barrierefreiheit" gefeatured wurde, so ist durch den Zugewinn an Usability genau diese entstanden.

Gruß Stefan

Das basiert auf JavaScript und ist per Definition daher nicht barrierefrei. Textvergrößerung kann jeder Browser von Hause aus. Eine barrierefreie Seite fliegt auch nicht auseinander, wenn man den Text mit der browsereigenen Funktion verkleinert oder vergrößert.

Textvergrößerung mit JavaScript ist daher vollkommen unnötig.

Warum vergessen die Leute, daß HTML ausgabeunabhängig ist? Wenn ihr den ursprünglichen Sinn von HTML noch wüßtet, dann würdet ihr euch a) eine Menge Probleme ersparen und b) solche "Lösungen" an die Wand klatschen. Absolut krank sowas.

 

[stk]

Moin,

Erst lesen, dann auf der Zunge zergehen lassen, ggf. verstehen und dann posten

Es geht nicht um Textvergrößerung per JS, sondern darum zu verarbeiten was passiert, wenn jemand Textvergrößerung nutzt.

Gruß Stefan

 

[MacMark]

stk, sowas ist bei einer barrierefreien Seite vollkommen unnötig. Man muß überhaupt nicht darauf reagieren, wenn der Besucher die Textgröße ändert, wenn die Seite barrierefrei ist. Sie bleibt nämlich weiterhin lesbar und benutzbar. Solche Probleme haben nur nicht-barrierefreie Seiten und, um ehrlich zu sein, ich gönne sie ihnen aus tiefstem Herzen, Strafe für den, der sie verdient.

 

[Hilarious]

Danke, stk, prima Fund und interessanter Ansatz!

 

[stk]

Moin,

Barrierefreiheit ist dazu gedacht, das alle mit einer Webseite umgehen können. Barrierefreiheit ist nicht dazu gemacht, allen einen kleinsten gemeinsamen Nenner unterzuschieben. Nur weil Seiten barrierefrei sind, müssen sie nicht sch…e aussehen. Hochwertiges Design, hohe Funktionalität, valider Code und in der Erweiterung Barrierefreiheit lassen sich (zumindest in meiner Welt) sehr wohl in Übereinstimmung bringen. Dort wo Design oder Funktion die Gefahr bergen der Barrierefreit in den Füßen zu stehen braucht es zusätzliche "Versöhnungsmechanismen". Im Falle von Funktionsanreicherung durch AJAX kann dies durch serverseitiges Fallback geschehen. Im (vorliegenden) Fall von optischen Einschränkungen (schau Dir mal das Beispiel mit der Navigation, die aus länglichen, zusammengesetzten Hauptwörtern - nicht unüblich in unserem Sprachgebrauch - besteht) können eben andere Konstrukte hilfreich sein.

Im Prinzip ist die Diskussion einigermassen deckungsgleich mit der "wir schreiben doch nicht Seiten für Suchmaschinen, sondern für Benutzer". Das ist genauso falsch oder richtig wie "wir schreiben doch nicht Seiten für Behinderte, sondern 'Nomale'". Eine Mehrheit von Usern sollte man nicht aus den Augen verlieren, schon gar nicht den Kunden, den i.d.R. Barrierefreiheit noch wesentlich weniger interessiert als Suchmaschinentauglichkeit und dennoch kann man mit einer wirklich gut gemachten Seite neben den "Normalo"-Ansprüchen auch noch Barrierefreiheit und Suchmaschinentauglichkeit unterbringen.

Gruß Stefan