Diskussion: client-server call

G

Guest

Guest
Hallo,

In diesem Thread möchte ich zu einer Diskussion anregen, die die Vor-und Nachteile von http_requests via "Easy" und "Ajax" behandelt.

Natürlich ist das auch Werbung in eigener Sache.

Trotzdem ist das Script auf www.fincy.com/easy_http_request wohl eine Diskussion wert.

Vorteile von easy sind:

1. einfache Handhabung
2. man braucht keine weiteren Programmierkenntnisse
3. globale Javascript-Variablen lassen sich auch im serverseitigen Script verändern
4. clientseitige Javascript-Funktionen kann im serverseitigen Script aufrufen
5. die serverseitge Programmiersprache lässt sich im serverseitigen Script mit Javascript verknüpfen.
 
okay, also keine Diskussion ist ja auch absolut cool.

Dann spendet mal schön.
 
Ich hatte mir deinen Beitrag mehrfach durchgelesen - und war mehrfach ratlos.

Der Blick nun auf die Domain hat die Ratlosigkeit eher bekräftigt.

Worin soll der Nutzen liegen?

Die von dir genannten Vorteile

QUOTE (Tuemmel @ Mi 9.01.2008, 15:18)1. einfache Handhabung
2. man braucht keine weiteren Programmierkenntnisse
3. globale Javascript-Variablen lassen sich auch im serverseitigen Script verändern
4. clientseitige Javascript-Funktionen kann im serverseitigen Script aufrufen
5. die serverseitge Programmiersprache lässt sich im serverseitigen Script mit Javascript verknüpfen.


sehe ich eher als Nachteile - da werden Dinge wie ein Spagetti-Code miteinander vermischt.

Deshalb würde ich - unter dem Gesichtspunkt einer einigermaßen brauchbar strukturierten Programmierung - von so einer Vermischung gerade abraten - damit natürlich auch von der Nutzung solcher Werkzeuge absehen (mal davon abgesehen, daß ich ohnehin nicht mit PHP arbeite).

Mach es doch mal umgekehrt: Warum hast Du das Bedürfnis gehabt, so etwas zu entwickeln? Welche Probleme hat das gelöst, die ohne dieses bis jetzt noch nicht lösbar waren? Vielleicht löse ich ja dieselben Probleme ganz anders - mit 'klassischen Mitteln'.
 
a. Das ist kein Mischmasch, sondern ein reines Javascript, dass in den Beipielen mit php-routinen abgearbeitet wird. Man kann auch jede andere serverseitige Sprache benutzen.

Statt einer Datei hätte ich auch z.B für den Chat 4 oder 5 serverseitige Dateien schreiben können, die die verschiedenen Funktionen getrennt abwickeln. Das wäre vielleicht übersichtlicher, ist aber nicht notwendig, da man clientseitige und serverseitige Operatoren verwenden kann.

b. das heisst, man kann auch mehrere requests auf einmal an den Server schicken, was bei ajax nicht geht.

c. Man braucht nicht zu warten bis ein return kommt, sondern kann das serverseitige script direkt in die clientseitige Scriptverarbeitung einbinden.

e. globale clientseitige Variablen lassen sich direkt serverseitig verändern und clientseitige Funktionen direkt aus dem serverseitigen Script aufrufen. Wer in Millisekunden rechnet, freut sich über den Geschwindigkeitsvorteil.

f. Man kann nach Belieben javascript cookies oder cookies in der serverseitigen Sprache setzen.

d. Wer javascript kann, braucht keine weiteren ( überflüssigen ) Kenntnisse für einen http request.

Es ist doch naheliegend die Möglichkeiten von Javascript direkt zu nutzen, statt ein kompliziertes Werk darum herum. Hast Du die Konstruktoren gesehen ? Als ich mein 1. Ajax Konstruktor gesehen haben, kam in mir wieder das Gefühl auf, Funktionen nur als Selbstzweck zu schreiben.

obj.eigenschaft1="etwas";
obj.eigenschaft2="etwas anderes";
funktioniert auch.

Wenn obj dann noch global ist, entspricht das exakt einem Prototyp.
Dann braucht man nur noch "neues_object=new Object(obj);"
ohne komplizierte Sprachwirrwarr.

Den Mischmasch mit überflüssigem Vokabular findest du doch eher in ajax,

aber wenigstens mal ein Anstoss zu einer Diskussion.

Danke Jürgen
 
QUOTE Warum hast Du das Bedürfnis gehabt, so etwas zu entwickeln?


Nachdem die Vorteile oben beschrieben sind, erklär ich noch kurz den Hintergrund.

Mein hitcounter wurde mit

document.write("<script src='url?var=x';</script>");

aufgerufen. Das funktionierte neben ff, etc. aber nur kurz in einer Version von ie6.

Nach Veröffentlichung des Hitcounters musste ich leider feststellen, dass die bösen Jungs von budu sofort kopiert haben. Die haben wirklich jedes Update von mir ein 2 Tage später im Netz gehabt. Dort sollte man sich besser nicht anmelden.

Jedenfalls kam die Lösung zu escapen:

document.write("\<script src='url?var=x';\<\/script\>");

Diese Lösung und ähnliche werden noch vielfach verwendet, sind aber in ie7 instabil, d.h. manchmal wird ein neues leeres Browserfenster geöffnet. Die Instabilität wurde in kontrollierte Wege geleitet, sodass man heute noch häufiger ein kleines Fensterchen sieht, dass sich kurz öffnet und dann nach dem kompletten Laden der Seite wieder schliesst.

Mit dieser Lösung war ich aber keineswegs zufrieden. Also habe ich die Lösung nach dem DOM entwickelt und ein paar Monate mit der Veröffentlichung gewartet, nachdem budu ihren Hitcounter aufgegeben hat. Das mich hat zwar auch ein paar Mitglieder gekostet, war aber zu verkraften.

Aus dem Hitcounter ist dann der http request geworden.

Zu Deiner Anmerkung, warum der Code so vermischt ist:

Das ist reine Gewohnheitssache. Im Augenblick schreibe ich gerade eine Applikation mit rund 100 verschiedenen Inhaltsseiten und 3-4 verschiedenen http_requests/Seite.
Wenn ich jetzt für jede Javascript-Funktion, die serverseitige Daten abfruft, in eine eigens dafür geschriebene Datei leiten würde, käme ich auf mindestens 1500-2000 request-Dateien, was der Übersicht nicht förderlich ist.
dry.gif


Indem möglichst viele verwandte Requests bezüglich einer Inhaltsseite in einer einzigen serverseitigen Datei geschrieben sind, kann ich die Anzahl auf im Augenblick 150 beschränken. Das dient dann auch einer übersichtlichen Verzeichnisstruktur. Jede Inhaltsseite hat neben allgemeingültigen serverseitigen request Dateien höchstens noch 2 serverseitige requests Dateien.

Wenn Du z.B. den Chat siehst, wirst Du feststellen, dass eigentlich ein request zum Schreiben einer neuen Message vorhanden ist, einer für Bewegungen, einer zur Initialisierung, einer zum Abrufen von Messages und einer zum Verlassen des Chats. Das wären 5 Dateien, die in eine einzige gepackt sind. So kann ich beim Programmieren in 2 Dateien bleiben, statt in 6 hin- und her navigieren zu müssen.


Mit Gruss

Bernd Reinhard Rickert




 
Der wohl gravierendste Vorteil ist, dass man auch session-Cookies in der aufzurufenden Datei benutzen kann. Das macht die javascript http request erheblich sicherer.

Ich bin mal gespannt, was für "framewurks-Ergänzungen" sich die ajax und mootools-Kollegen dazu einfallen lassen. Das wird diese "Sprachen" sicher um einiges an Vokabular bereichern.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben