async behandlung
bleicher
- javascript
Grüße,
ich weiß, dies ist eher ein Doppelposting, aber ich hoffe es wird leben gelassen - immerhin geht es jetzt nicht um html5 sondern um JS-spezifische Sache
sowohl AJAX als auch das tolle neu WebDatabase arbeiten Asynchron, soweit ich das verstehe, hat man keine große Wahl, außer eine Funktion zu definieren/übergeben die ausgeführt wird, sobald sich die datenquelle erbarmt.
könnte man dennoch irgendwie die Struktur
daten=request(par);
erreichen?
ich habe versucht eine Funktion mit "Methoden" zu versehen, die sich gegenseitig aufrufen und das Ergebnis in eine Eigenschaft der request fkt schrieben, die nachher mit return this.result;,
funktioniert aber nicht, sobald ich nacheinander mehr als ein request starte
was ist die übliche Vorgehensweise beim anfordern der Daten asynchron, sei es webdatabase oder Server über ajax?
MFG
bleicher
AJAX ist zwar dem Namen nach asynchron, der dahinterstehende XMLHttpRequest jedoch auch zur synchronen Behandlung fähig:
// xhr sei unser Request-Objekt
xhr.open(URL, Method, isAsync)
In diesem Fall ist isAsync ein boolean - und für synchrone Request übergebe ganz einfach "false". Schon wird der Thread so lange geblockt, bis das Ergebnis da ist.
Achtung: Firefox neigt dazu, Events selbst dann zu blocken, wenn man synchrone Requests mit window.setTimeout aus dem Thread herauszunehmen versucht. In diesem Fall bleibt lediglich ein asynchroner Request oder noch eleganter, JSONp.
Gruß, LX
könnte man dennoch irgendwie die Struktur
daten=request(par);
erreichen?
Ja, in dem du diese in einer Funktion kapselst und diese aufrufst, wenn der asynchrone Vorgang beendet ist.
was ist die übliche Vorgehensweise beim anfordern der Daten asynchron, sei es webdatabase oder Server über ajax?
Genau wie bei allen anderen Eventgesteuerten Aktionen. Du musst deinen Programmfluss entsprechend anpassen.
Struppi.
Grüße,
Ja, in dem du diese in einer Funktion kapselst und diese aufrufst, wenn der asynchrone Vorgang beendet ist.
verstehe ich nicht ganz?
bisher war mein versuch
(inetwa)
function getdata(query){
this.rows=0;
...
//datenanfragen,callback bei erfolgter abfrage:callback
// die datenanfrage erfolgt hier asynchron
...
callback:function(e,r){
getdata.rows=r;
}
return this.rows;
}
was mächtig shcief läuft
Genau wie bei allen anderen Eventgesteuerten Aktionen. Du musst deinen Programmfluss entsprechend anpassen.
wie denn? dass ich was änern muss ist klar, aber in welche richtung?
MFG
bleicher
bisher war mein versuch
(inetwa)
function getdata(query){
this.rows=0;
...
//datenanfragen,callback bei erfolgter abfrage:callback
// die datenanfrage erfolgt hier asynchron
...
callback:function(e,r){
getdata.rows=r;
}
return this.rows;
}was mächtig shcief läuft
Weil du etwas zurück gibst was es (noch) nicht gibt. Nur in der callback Funktion hast du Zugriff auf die Werte.
Genau wie bei allen anderen Eventgesteuerten Aktionen. Du musst deinen Programmfluss entsprechend anpassen.
wie denn? dass ich was änern muss ist klar, aber in welche richtung?
Naja, genau wie bei einem onclick oder onmousemove. sowas läuft nicht chronologisch ab, sondern es passiert etwas, wenn ein bestimmter Auslöser die Aktion anstößt.
Wie genau du das in deinem speziellen Fall machen musst, kann man dir nicht sagen, da wir nicht Wissen, was du konkret vor hast. Du kannst aber nur in der callback Funktion auf die Daten zugreifen.
Struppi.
Grüße,
Wie genau du das in deinem speziellen Fall machen musst, kann man dir nicht sagen, da wir nicht Wissen, was du konkret vor hast. Du kannst aber nur in der callback Funktion auf die Daten zugreifen.
was ist, wenn man die funktion selbst als callback definiert, und unterscheidung am übergebenem argument macht?
würde es zur rekursion führen, bzw die feste abfolge erzwingen, oder würde die aufrufende funktion "der ersten ordnung" einfach weiterlaufen ohne aufreturn der callback zu warten? ich vermute schon :/
was bleibt da noch übrig?
MFG
bleicher
Wie genau du das in deinem speziellen Fall machen musst, kann man dir nicht sagen, da wir nicht Wissen, was du konkret vor hast. Du kannst aber nur in der callback Funktion auf die Daten zugreifen.
was ist, wenn man die funktion selbst als callback definiert, und unterscheidung am übergebenem argument macht?
Das verstehe ich nicht, welche Funktion?
Struppi.
Grüße,
Das verstehe ich nicht, welche Funktion?
das war mein erster versuch, teilweise gelöscht und glaube ich so fehlerhaft (nicht getestet)
function sql(q,d){//q=query, d=database
if(d!=undefined){
this.db=d;
}else if(d==undefined && this.db==undefined){
alert("db nicht spezifiziert!");
return false;
}
this.rows=0;
db.transaction(trcallb,trok,trerr);
var trcallb=function(t){
t.executeSql(q,[],stok,sterr);
}
var trok=function(){
}
var trerr=function(o,e){
alert(e.message);
}
var stok=function(o,r){
rows=r.rows;
}
//sterr vergessen^^
return this.rows;
}
sql("SELECT * FROM test", openDatabase("test","1","testDB",2000));
das Problem ist, dass return ausgeführt wird, bevor stok den rückgabewert in rows reinschreibt.
nun könnte ich eine funktion als 3ttes argument übergeben -
function sql(q,d,f){//q=query, d=database,f=function
....
....
var stok=function(o,r){
f(r.rows);
}
aber auch da hatte ich seltsame Sachen - ich hab das Gefühl, dass mehrfaches aufrufen der funktion sql() hintereinander dazu führt, dass voriges request einfach überschrieben wird :/
MFG
bleicher
Grüße,
Das verstehe ich nicht, welche Funktion?
das war mein erster versuch, teilweise gelöscht und glaube ich so fehlerhaft (nicht getestet)
function sql(q,d){//q=query, d=database
if(d!=undefined){
this.db=d;
Was soll das this hier? allein schon dieser Ansatz ist grundlegend falsch. this ist nämlich gleich window, d.h. du hast eine globale Variabel, was bei sowas, mit ziemlicher Sicherheit zu Problemen führt.
}else if(d==undefined && this.db==undefined){
Das könntest du dir auch einfacher machen:
}else if(!d && !this.db){
Wobei, this.db vermutlich nicht das ist was du möchtest.
db.transaction(trcallb,trok,trerr);
Ich kenn mich damit nicht aus, aber ich vermute, da sind alles callback Funktionen. Wieso werden die erst danach definiert? Das müßte eigentlich zu einem Fehler führen, kennst du die Fehlerkonsole?
var stok=function(o,r){
rows=r.rows;
Nur hier kannst du auf r zugreifen. Nur hier!!!!
}
//sterr vergessen^^return this.rows;
Das hat keinen Nutzen.
das Problem ist, dass return ausgeführt wird, bevor stok den rückgabewert in rows reinschreibt.
Das Wissen wir jetzt seit beginn dieses Threads.
nun könnte ich eine funktion als 3ttes argument übergeben -
Das ist die einzige Möglichkeit die du hast, das wäre die schon erwähnte Callback Funktion.
function sql(q,d,f){//q=query, d=database,f=function
....
....var stok=function(o,r){
f(r.rows);
}
Genau, so funktioniert das.
> aber auch da hatte ich seltsame Sachen - ich hab das Gefühl, dass mehrfaches aufrufen der funktion sql() hintereinander dazu führt, dass voriges request einfach überschrieben wird :/
Absolut, weil du mit globalen Variabeln arbeitest und nicht darauf reagierst wenn ein Request noch nicht fertig ist. Das muss in deine Funktion auch noch eingebaut werden.
Struppi.
Grüße,
danke für die korrektur ^^ das klärt einiges
Was soll das this hier? allein schon dieser Ansatz ist grundlegend falsch. this ist nämlich gleich window, d.h. du hast eine globale Variabel, was bei sowas, mit ziemlicher Sicherheit zu Problemen führt.
das habe ich mittlerweile auch rausgekriegt, also war wohl der versuch das hier zu verstehen misslungen
Ich kenn mich damit nicht aus, aber ich vermute, da sind alles callback Funktionen. Wieso werden die erst danach definiert? Das müßte eigentlich zu einem Fehler führen, kennst du die Fehlerkonsole?
seltsamerweise nicht, ist es bei JS nicht so, dass die definitionsreihenfolge keine rolle spielt? ich kann ja nicht wie bei C die definitionen vor den rümpfen ziehen?
Das ist die einzige Möglichkeit die du hast, das wäre die schon erwähnte Callback Funktion.
schade ;/ das wird die anzahl der nötigen funktionen explodieren lassen :/
Genau, so funktioniert das.
ermutigend^^
Absolut, weil du mit globalen Variabeln arbeitest und nicht darauf reagierst wenn ein Request noch nicht fertig ist. Das muss in deine Funktion auch noch eingebaut werden.
wie soll ich das sonst angehen?
mit
var req1=new sql(blabla...);
var req2=new sql(ande4res dingsbums...);
oder wie?
ich lese in der zwischenzeit slehtml zum thema JSoop, aber ein tipp würde mir stunden sparen^^
danke im voraus
MFG
bleicher
das habe ich mittlerweile auch rausgekriegt, also war wohl der versuch das hier zu verstehen misslungen
Ja, das ist ein Konstruktor, d.h. du musst ihn mit new Funktion() aufrufen, dann hast du eine Instanz des Objekts.
Ich kenn mich damit nicht aus, aber ich vermute, da sind alles callback Funktionen. Wieso werden die erst danach definiert? Das müßte eigentlich zu einem Fehler führen, kennst du die Fehlerkonsole?
seltsamerweise nicht, ...
Seltsamerweise bei mir schon. Du weißt wirklich wo und was die Fehlerkonsole ist?
Das ist die einzige Möglichkeit die du hast, das wäre die schon erwähnte Callback Funktion.
schade ;/ das wird die anzahl der nötigen funktionen explodieren lassen :/
Wieso? Du brauchst eine einzige Callbackfunktion. Wie gesagt, das ist das gleiche Prinzip wie bei normalen Events.
mit
var req1=new sql(blabla...);
var req2=new sql(ande4res dingsbums...);
Das ist eine Möglichkeit, aber vermutlich nicht praktikabel. Nein, du musst in dem Objekt triggern, dass du noch auf die Antwort wartest und erst dann einen neuen Request zulassen, wenn diese erfolgt ist. Dazu gibt es eben diese Callbackfunktionen.
Ganz grob in etwa so:
function Sql(db) {
var _this = this; // Kopie für die callback Funktion
var callback = function(erg) {
this.isBusy = false;
_this.onload(erg)
}
this.isBusy = false;
this.do = function(sql) {
if(this.isBusy) return false;
isReady = false;
// mach_deinen_request
db.transaction( callback, ...);
return true;
};
this.onload = function() {}; // Dummy, wird überschrieben
}
var req = new Sql( .... );
req.onload = function(ret) {
alert(ret); // rückgabe
};
req.do( 'SQL befehl');
ich lese in der zwischenzeit slehtml zum thema JSoop, aber ein tipp würde mir stunden sparen^^
Da hatr selfhtml relativ wenig zu bieten, da OOP in JS absolut kein Anfänger Thmea ist.
Struppi.
Grüße,
Seltsamerweise bei mir schon. Du weißt wirklich wo und was die Fehlerkonsole ist?
sogar Dragonfly benutzt^^
das schrittweise beobachten brachte mich eben auf die olle idee das gaze funktioniere nicht wegen der async
wobei ich sagen muss - die o.g. funktion habe ich so ncih tbenutzt, und nur zwecks beispiel gebracht - uU habe ich im original zufällig die richtige reihenfolge gehabt
Da hatr selfhtml relativ wenig zu bieten, da OOP in JS absolut kein Anfänger Thmea ist.
jupp, dann werde ich mich wohl , falls ich das aktuelle vorhaben umsetze, arrogant genüg fühlen selfwiki mit entsprechendem eintrag zu besudeln^^
MFG
bleicher
das schrittweise beobachten brachte mich eben auf die olle idee das gaze funktioniere nicht wegen der async
wobei ich sagen muss - die o.g. funktion habe ich so ncih tbenutzt, und nur zwecks beispiel gebracht - uU habe ich im original zufällig die richtige reihenfolge gehabt
Wahrscheinlich.
Ich habe deinen Code in ein lauffähiges Beispiel umgesetzt:
function f1() { // so wie du es gezeigt hast
fb(x);
var x = function() {alert('Hallo');};
}
function f2() { // so geht's
var x = function() {alert('Hallo');};
fb(x);
}
function fb(c) {c();}
try {f1();} catch(e) {alert(e);}
try {f2();} catch(e) {alert(e);}
Der erste Aufruf erzeugt einen Fehler, der zweite sagt Hallo.
Struppi.
Grüße,
danke - ich passe das an^^
wobei das hauptproblem momentan ist - wenn ich den ansatz so ausführe - wird der 2e request falls der erste noch läuft einfach verworfen, ich kriege false und das wars - würde es sinn machen den request in schleife zu wiederholen "bis es klappt" oder wird es den browser killen^^?
MFG
bleicher
wobei das hauptproblem momentan ist - wenn ich den ansatz so ausführe - wird der 2e request falls der erste noch läuft einfach verworfen, ich kriege false und das wars - würde es sinn machen den request in schleife zu wiederholen "bis es klappt" oder wird es den browser killen^^?
Das ist dann die Frage wie das ganze entworfen ist.
Sinnvollerweise würde man versuchen, den näxten Request nicht abzusetzen, bevor der erste fertig ist (also in der callback Funktion).
Struppi.