nicht angemeldet
javascript / Ajax / php ausführung sicherstellen
JürgenB
StruppiHallo,
ich hab eine kleines Script gebaut mit dem ich aus einer Datenbank mittels php Zeug auslese und in HTML ausgebe. Mittels Javascript und Ajax hab ich eine einfache Drag'n'Drop-Funktion geschrieben mit der ich die Zeilen der Tabelle umsortieren kann. Das funktioniert auch wunderbar, wenn man das schön langsam macht. Aber wenn man mal etwas schneller die Tabellenzeilen hin und herschiebt sieht zwar die Tabelle noch richtig aus (Javascript) aber das Ajax das eine weitere php Datei aufruft um die Datenbankmanipulation durchzuführen kommt nicht mehr hinterher. Das sieht man daran das nach einem Seiten reload nicht die richtige Zeilenanordnung aus der DB gelesen wurde.
Meine Frage also, gibts eine Möglichkeit die Ausführung des Javascripts auf einen Zeitpunkt zu verschieben wenn die Datenbankmanipulation abgeschlossen ist?
Danke und viele Grüße,
Rob
-
Hallo,
... Das sieht man daran das nach einem Seiten reload nicht die richtige Zeilenanordnung aus der DB gelesen wurde.
Du nachvollziehst also in der Datenbank die gewünschte Sortierfolge eines Users - für alle anderen User auch?
Ich frage dewshalb, ob das überhaupt eine Aufgabe für den (überlasteten) Server ist. Es gibt doch auch die Möglichkeit, eine Tabelle ohne Serverkontakt umzusortieren.
Kalle
-
Hallo Kalle,
Du nachvollziehst also in der Datenbank die gewünschte Sortierfolge eines Users - für alle anderen User auch?
Die Umsortierung findet nicht Spaltenorientiert statt, falls Du das denken solltest, sondern Zeilensepariert und vom Nutzer gesteuert statt. Der user manipuliert also gewollt den DB-Inhalt mit Hilfe der Tabelle.
Ich frage dewshalb, ob das überhaupt eine Aufgabe für den (überlasteten) Server ist. Es gibt doch auch die Möglichkeit, eine Tabelle ohne Serverkontakt umzusortieren.
Es geht ja nicht um das anzeigen einer sortieren Tabelle sondern das händische Umsortieren von Datenbankinhalten. Also die Änderungen der Positionen einzelner Zeilen von Hand. dazu muss der server ja wissen was der user geändert hat und muss diese Änderung in die DB schreiben.
Grüße
Rob
-
-
h1,
Meine Frage also, gibts eine Möglichkeit die Ausführung des Javascripts auf einen Zeitpunkt zu verschieben wenn die Datenbankmanipulation abgeschlossen ist?
Die Lösung heißt: Preload. Du holst Dir alle Daten, die Du brauchst, mit Ajax, speicherst die in einem Object und wenn Du alles hast, kannst Du die Daten ratz fatz im Browser hinundherschieben, da ruckelt dann nichts mehr.
Hier ein Beispiel fürs Preload:
http://rolfrost.de/cgi-bin/amovie.cgiHotti
-
Hallo RobRobson,
Meine Frage also, gibts eine Möglichkeit die Ausführung des Javascripts auf einen Zeitpunkt zu verschieben wenn die Datenbankmanipulation abgeschlossen ist?
den "onreadystatechange" abwarten.
Gruß, Jürgen
-
h1,
den "onreadystatechange" abwarten.
Wieso: 'den'?
Bei größeren Datenmengen hab ich mit Sicherheit 'mehrere' ;-)
Da werden die Requests getagged, das jeweilige tag serverseitig in den ResponseHeader geschrieben und damit werden alle asynchronen Responsen im DOM in einem Array() wieder vereinigt. Für die Übertragung einer Tabelle würde ich je Record einen getagged'n Ajaxrequest machen und innerhalb einer Response die Felder linear strukturieren wie das bei einem URI gemacht wird (Escape). Das kriegst Du mit split(&) und decodeURIComponent() ratz fatz und knitterfrei wieder in die Einzelkomponenten geparst.
Hotti
-
Mahlzeit hotti,
den "onreadystatechange" abwarten.
Wieso: 'den'?
Weil es bei jedem XHR-Objekt nur *genau einen* Event-Handler namens "onreadystatechange" gibt?
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|-
Mahlzeit hotti,
Maaaahlzeit ;-)
den "onreadystatechange" abwarten.
Wieso: 'den'?
Weil es bei jedem XHR-Objekt nur *genau einen* Event-Handler namens "onreadystatechange" gibt?
Achsoja, na klar. Aber warum sollte ich nur _ein_ xhr-Objekt haben wollen? Da muss ich ja, wenn ich mehrere asynchrone Requests rausschicken will (*), jedesmal warten, bis der fertig ist! Ist das der Sinn von asynchron? Klares Nein ;-)
(*) Das geht ab, so als würden mehrere Kühe fliegen! Wenn asynchron, dann richtig *g*
Hotti
-
Achsoja, na klar. Aber warum sollte ich nur _ein_ xhr-Objekt haben wollen? Da muss ich ja, wenn ich mehrere asynchrone Requests rausschicken will (*), jedesmal warten, bis der fertig ist! Ist das der Sinn von asynchron? Klares Nein ;-)
Der Sinn von asynchron ist, der das du den Browser nicht einfrierst.
Die Anzahl der Request ist beschränkt, je nach Browserkonfiguration, insofern solltest du durchaus aufpassen, dass die Anzahl der Request nicht zuviele werde und du den Handler nicht überschriebst bevor er fertig ist.
Struppi.
-
hi,
Die Anzahl der Request ist beschränkt, je nach Browserkonfiguration, insofern solltest du durchaus aufpassen, dass die Anzahl der Request nicht zuviele werde und du den Handler nicht überschriebst bevor er fertig ist.
Vielen Dank für Deinen Hinweis, lieber Struppi. Gleich mal nachschauen, was da so geht ;-)
Multiple Requests sind ja auch nur eine Möglichkeit von Vielen, wenn es darum geht, multipart Content zu übertragen.
Die Umwandlung von MC in eine Textstruktur ist im Grunde genommen auch nur ne mächtige Frickelei, guck Dir RFC 2045 an (MIME). Das ist dann auch irgendwo ne politische (*) Frage, technisch hingegen sind da noch ganz andere Dinge möglich, wie z.B. eine asynchrone Übertragung von Multipart Content (bei einer MIME Mail könnte ich auch alle Parts gleichzeitig/asynchron als Binary übertragen und nicht hintereinander als ASCII Text).
(*) siehe DSL, wie lange hats gedauert hier in DE... die ami's hahm das schon ewig. Politik, Marktwirtschaft, Wettbewerbsgleichheit... das spielt da alles rein.
Im Chemnitz hatte ich einen Dozenten, Horst J., der hat Artikel geschrieben zum Thema Schaltnetzteile damals, und der hat immer gesagt: Wenn wir bessere Transistoren hätten, bräuchten wir nicht solche umständlichen Schaltungen zu entwerfen. Und das bezog er nicht nur auf Bauelemente der DDR-Produktion!
Bei den Browsern ist das heute ganz ähnlich, z.B. kann auch ie 8 immer noch kein URL-SChema data:image/gif;binary,<DATA> darstellen, base64 hingegen schon. Andere Browser können beides (Marktwitschaftliche Aspekte???).
Aber ich schweife ab {..}
Viele Grüße,
Horst Haselhhun-
Multiple Requests sind ja auch nur eine Möglichkeit von Vielen, wenn es darum geht, multipart Content zu übertragen.
Ich weiß nicht, was du mir damit sagen willst, es hat aber nichts mit dem zu tun was ich dir gesagt hatte.
... technisch hingegen sind da noch ganz andere Dinge möglich, wie z.B. eine asynchrone Übertragung von Multipart Content (bei einer MIME Mail könnte ich auch alle Parts gleichzeitig/asynchron als Binary übertragen und nicht hintereinander als ASCII Text).
Wie gesagt asynchron heißt hier lediglich, dass dein Browser nicht einfriert. Die Daten an sich werden synchron übertragen. Ich glaube der email Verkehr läuft ähnlich ab. Wie dann letztlich die Nutzdaten behandelt werden ist von der Art und weise der Übertragung völlig unabhängig.
Struppi.
-
h1,
Ich weiß nicht, was du mir damit sagen willst, es hat aber nichts mit dem zu tun was ich dir gesagt hatte.
jaja, so sind wir halt ;-)
Was ich bei meinen Recherchen auch oft feststelle: Gesagt wird *gleichzeitig* aber gemeint ist *asynchron*
Also, wenn du mal Zeit hast:
http://rolfrost.de/cgi-bin/amultirequest.cgiDa steht nicht nur was ich meine, das zeigt Dir auch was ich meine: Mehrere Requests asynchron zum Download von Multipart Content (Bild, Text, Blob) in tagged Responses (Etag).
Rolf
-
Da steht nicht nur was ich meine, das zeigt Dir auch was ich meine: Mehrere Requests asynchron zum Download von Multipart Content (Bild, Text, Blob) in tagged Responses (Etag).
Das Beispiel von dir zeigt meiner Meinung nach nur, das man es besser machen könnte.
Die Daten Vorname, Name und Zusatz gehören eindeutig zusammen und da verstehe ich nicht den Grund hier mehrere Requests (auch mit dem damit verbundenem Overhead) zu nutzen.
Was Blob ist, keine Ahnung. Mit Binärdaten kann JS nichts anfangen (wüsste auch nicht wozu).
Ein Bild Base64-Kodiert zu übertragen ist in den meisten Fällen auch Sinnfrei.
Es gibt sicher Fälle, mit vielen Daten, wo es auch sinnvoll ist zusammengehörende Daten getrennt zu übertragen, hier aber sicher nicht.-
hi,
Die Daten Vorname, Name und Zusatz gehören eindeutig zusammen und da verstehe ich nicht den Grund hier mehrere Requests (auch mit dem damit verbundenem Overhead) zu nutzen.
Meine Demo zeigt das Prinzip.
Was Blob ist, keine Ahnung. Mit Binärdaten kann JS nichts anfangen (wüsste auch nicht wozu).
JS muss mit biärdaten überhaupt nichts anfangen können. JS dient nur dazu, diese Daten in ein Object zu schreiben, z.B. um solch ein Objekt an einen Multimediaplayer übergeben zu können. Und dass es einem Player wie f lash Plugin nicht unbedingt bedarf, das zeigt mein Kurzfilm
http://rolfrost.de/cgi-bin/amovie.cgi
Ein Bild Base64-Kodiert zu übertragen ist in den meisten Fällen auch Sinnfrei.
s.o.: Nicht ein Bild, sondern Mehrere. Der Besucher sieht einen Film!
Es gibt sicher Fälle, mit vielen Daten, wo es auch sinnvoll ist zusammengehörende Daten getrennt zu übertragen, hier aber sicher nicht.
Nochmal: Das *hier* ist eine Demo. Die zeigt, wie einfach das ist.
Und einen Test linear zu strukturieren, ist noch einfacher:
http://rolfrost.de/cgi-bin/alib.cgi
Auf diese Art und Weise kann ich auch einen Multipart content übertragen
http://rolfrost.de/cgi-bin/amime.cgi
So, genug geschwätzt. Wie Ihr sehen könnt, ist json nicht alles ;-)
Nochwas zu Blob/binaries, es gibt Browser (außer ie) die verstehen hexmaps als binary, da ist ein noch eine Demo:
http://rolfrost.de/cgi-bin/abin.cgi
Tut mir leid, wenn Du damit nix anfangen kannst. Aber es gibt Leute, die reißen sich um solche Dinge.
Rolf
-
Nochwas zu Blob/binaries, es gibt Browser (außer ie) die verstehen hexmaps als binary, da ist ein noch eine Demo:
Nur noch eine Frage hierzu.
Was heisst "verstehen hexmaps als binary" und was bedeutet "außer ie"?
Prinzipiell ist deine hexmap ja schon mal kein Binary, sondern ein String!
Was meinst du also?
-
-
-
Da steht nicht nur was ich meine, das zeigt Dir auch was ich meine: Mehrere Requests asynchron zum Download von Multipart Content (Bild, Text, Blob) in tagged Responses (Etag).
Ich habe nie bestritten das parallel Request gehen, allerdings ist die Anzahl je nach Browser eingeschränkt.
Im IE 6 klappt dein Beispiel bei mir nicht, vermutlich da dieser i.d.R. nur 2 parallele Requests zuläßt, Firefox 6.
Wobei ich nicht verstehe, wo du den Vorteil siehst.
Struppi.
-
-
-
-
-
Hi,
Aber warum sollte ich nur _ein_ xhr-Objekt haben wollen? Da muss ich ja, wenn ich mehrere asynchrone Requests rausschicken will (*), jedesmal warten, bis der fertig ist! Ist das der Sinn von asynchron? Klares Nein ;-)
Hier ist aber offenbar das Problem, dass ein erneuter Aufruf der Darg&Drop-Funktion erst möglich sein soll, wenn das Ergebnis der vorherigen sicher am Server angekommen ist.
Es ist also eine synchrone Verarbeitung gewünscht.(Dafür muss man den Request nicht synchron machen, weil das wie erwähnt den Browser einfriert - aber eben mit dem Absetzen des nächsten Requests so lange warten, bis der aktuelle fertig ist.)
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
-
-
Moin Moin,
Mahlzeit hotti,
den "onreadystatechange" abwarten.
Wieso: 'den'?
Weil es bei jedem XHR-Objekt nur *genau einen* Event-Handler namens "onreadystatechange" gibt?
(Ich bin kein große Ajax Auskenner!!)
Aber ich warte doch den onreadystatechange ab oder?xmlHttpObject.open('get','include/edit_todo_ajax.php?start='+startid+'&ende='+endid);
xmlHttpObject.onreadystatechange = handleContent;
xmlHttpObject.send(null);
return false;die Funktion handleContent prüft mittels "if (xmlHttpObject.readyState == 4)" ob die Datei richtig eingelesen wurde. Und gibt mir dessen Rückgabewert mittels "xmlHttpObject.responseText".
viele Grüße,
RobPS: Ich hab die Funktion jetzt umgebaut, das Problem BESTEHT also NICHT MEHR. Ihr braucht euch nicht weiter den Kopf zu zermartern. :-P
Jetzt lade ich nach jeder Aktion (1x Drag'n'Drop) die Tabelle neu aus der DB und sehe somit immer den aktuellesten Datenbestand.
Zur Erklärung. Erst war es so das ich mittels JS einen AnzeigenLayer kreirt hatte. Also mit JS wurde die Tabelle bei jeder D&D Aktion so verändert wie die Änderungen in die DB geschrieben wurden. Jetzt sichere ich das ab in dem ich auf den Reload der ganzen Tabelle warte. Das ruckelt dann zwar manchmal aber das ist verkraftbar wenn man dafür sicher sein kann das die Änderungen des D&D auch wirklich übernommen werden.
Vielen Dank und viele Grüße,
RobRobson
-
-
-