ajax response buffer

[hotti]

moin,

bei mir schreibt die Funktion, die in
xhr.onreadystatechange = rx;
notiert ist, einen Buffer, da kommt die Response zeitverzögert an (asynchron). Ich suche nun, eine elegante Lösung für

"Schreibe Buffer in das Dokument"

im Fall, dass sich das, was schon im Dokument steht, vom Buffer unterscheidet.

Im einfachsten Fall lasse ich eine IntervallFunktion losrennen, die regelmäßig nachschaut, aber das ist nicht vornehm. Gibts da noch was Eleganteres?

Bitte mal um Hinweise,
Horst

[Struppi]

notiert ist, einen Buffer, da kommt die Response zeitverzögert an (asynchron). Ich suche nun, eine elegante Lösung für

"Schreibe Buffer in das Dokument"

im Fall, dass sich das, was schon im Dokument steht, vom Buffer unterscheidet.

Das verstehe ich nicht. Inwiefern soll sich das was im Dokument steht (wo dort?) von dem Response unterscheiden? Der Response kann ein Text oder XML Dokument sein, das Dokument ist (vermutlich) ein HMTL Dokument. Die unterschieden sich immer.

Struppi.

[hotti]

Das verstehe ich nicht.

Ganz einfach. In der response Funktion steht, wo die Response hin soll, also wohin ins Dok. Ich hab aber keine Böcke mehr, für jedes Dok ne extra responseFunktion zu schreiben.

Hotti

[Struppi]

Das verstehe ich nicht.

Ganz einfach. In der response Funktion steht, wo die Response hin soll, also wohin ins Dok. Ich hab aber keine Böcke mehr, für jedes Dok ne extra responseFunktion zu schreiben.

Ich verstehe es immer noch nicht. wozu brauchst du da ein Interval?

Struppi.

[hotti]

Das verstehe ich nicht.

Ganz einfach. In der response Funktion steht, wo die Response hin soll, also wohin ins Dok. Ich hab aber keine Böcke mehr, für jedes Dok ne extra responseFunktion zu schreiben.

Ich verstehe es immer noch nicht. wozu brauchst du da ein Interval?

Ausführlich: Wenn meine responseFunktion rx() die Response gleich in das Dok schreibt, siehst Du die gleich. Tatsächlich aber kommt die zeitverzögert. Unschön ist dabei, dass rx() ans Dok gebunden ist, das will ich nun trennen, also etwas universeller machen.

Ergo schreibt rx() die Response in einen Buffer, ein globales Object. Ich weiß aber nicht, wann die Resp. ankommt, also setz ich eine IntervalFunktion drauf. Wenn Die aber alle Sekunde den Buffer in das Dok schreibt, flackert das Bild. Das Flackern kann ich vermeiden, wenn ich vor dem Schreiben Buffer => Dok ins Dok schaue zum Prüfen, ob sich was geändert hat. Das alles ist aber auch nicht sooo schön, da müsste ich ja wieder das Dok abfragen... hole in the bucket ;-)

Es ist nunmal ajax, aber ich hab nur ein Event, was den Request rausschickt. Zu dem Zeitpunkt jedoch, ist die Response noch nicht da. Andere Variante: Ich setze ein Timeout, hätte damit jedoch eine fest eingebaute Zeitverzögerung.

Andere Idee? Oder: Wo krieg ich ein Event her, was mir sagt: Die Response ist da!?

Hotti

[Struppi]

Ausführlich: Wenn meine responseFunktion rx() die Response gleich in das Dok schreibt, siehst Du die gleich. Tatsächlich aber kommt die zeitverzögert. Unschön ist dabei, dass rx() ans Dok gebunden ist, das will ich nun trennen, also etwas universeller machen.

Inwiefern ist rx() an's Dokument gebunden? Jede Funktion ist an das Dokument gebunden in der sie eingebunden wird.

Ergo schreibt rx() die Response in einen Buffer, ein globales Object. Ich weiß aber nicht, wann die Resp. ankommt, ...

Wieso nicht? Wir reden doch von AJAX oder? Dann wird der event onreadystate gefeuert, wenn der Response ankomt.

Es ist nunmal ajax, aber ich hab nur ein Event, was den Request rausschickt.

Das ist falsch.

Struppi.

[hotti]

hi,

Wieso nicht? Wir reden doch von AJAX oder? Dann wird der event onreadystate gefeuert, wenn der Response ankomt.

Ja, freilich. Da hab ich die Response bisher immer direkt in das Dokument geschrieben.

Hotti

[Struppi]

Wieso nicht? Wir reden doch von AJAX oder? Dann wird der event onreadystate gefeuert, wenn der Response ankomt.

Ja, freilich. Da hab ich die Response bisher immer direkt in das Dokument geschrieben.

Wann willst du den Response sonst schreiben?

Struppi.

[hotti]

Wann willst du den Response sonst schreiben?

Wollte: Erst schreiben in Buffer.
Das Puffern ist problematisch, es würde gut gehen, aber es braucht Overhead.

Ich werde nun die Response in onreadystatechange nach wie vor in das Dok schreiben, da bleibt alles beim Alten. Was ich onreadystatechange jedoch mitgeben werde (*), ist ein object, wo drinsteht, was <wohin> gehört oder ob eine <ul> oder eine <tab> oder <sonstwas> erstellt werden soll, damit das Ganze scalierbarer wird, als es bisher ist.

* Plan B :-)

Bis bald,
viele Grüße an Alle,
schönes Wochenende,
Horst Haselhuhn

[Struppi]

Wann willst du den Response sonst schreiben?

Wollte: Erst schreiben in Buffer.

Das macht doch keinen Sinn, du willst etwas buffern was noch nicht da ist?

Das Puffern ist problematisch, es würde gut gehen, aber es braucht Overhead.

Das verstehe ich wieder nicht.

Ich werde nun die Response in onreadystatechange nach wie vor in das Dok schreiben, da bleibt alles beim Alten. Was ich onreadystatechange jedoch mitgeben werde (*), ist ein object, wo drinsteht, was <wohin> gehört oder ob eine <ul> oder eine <tab> oder <sonstwas> erstellt werden soll, damit das Ganze scalierbarer wird, als es bisher ist.

Ich glaube du möchtest eine callback Funktion definieren, die dann zum Zeitpunkt des ladens aufgerufen wird und die Aktionen macht.

Struppi.

[hotti]

Wann willst du den Response sonst schreiben?

Wollte: Erst schreiben in Buffer.

Das macht doch keinen Sinn, du willst etwas buffern was noch nicht da ist?

Nanana, wenn ich schon puffere, dann richtg ;-)

Also die Response kommt irgendwann an im responseBuffer...

Das Puffern ist problematisch, es würde gut gehen, aber es braucht Overhead.

Das verstehe ich wieder nicht.

... der Overhead ist ein zweiter Puffer, der zwischen einer dispatcher()Funktion und dem Dokument steht, damit kein Flackern auftritt.

Ich glaube du möchtest eine callback Funktion definieren, die dann zum Zeitpunkt des ladens aufgerufen wird und die Aktionen macht.

Genau. Die callback()(Danke für den Begriff) schreibt die Response entweder in den responseBuffer (Plan A) oder gleich in das Dokument (Plan B).

Plan A: Eine Funktion dispatcher() verhandelt zwischen responseBuffer und den HTML-Elementen im Dokument. Hierzu muss dispatcher() wissen, wo was hingehört.

Plan B: callback() schreibt die Response in das Dokument, hierzu muss die callback() wissen, wo was hingehört.

Schreibaufwand A vs. B:
A Muss nur eine relativ kleine dispatcher() Funktion für das Dokument schreiben bzw. anpassen, der Rest geht automatisch.

B Muss die callback() zum Dokument passend machen. Eine 'Universelle' callback() zu Schreiben ist relativ aufwändig.

Ich habe A und B getestet und bin am Überlegen, ob sich der Aufwand lohnt, eine universelle callbackFunktion zu schreiben.

Hotti

[Struppi]

B Muss die callback() zum Dokument passend machen. Eine 'Universelle' callback() zu Schreiben ist relativ aufwändig.

Nein, ist es nicht.

var calback = function(response) {  
var out = document.getElementById('out');  
if(out) out.innerHMTL = response.innerText;  
}  

und die Funktion musst du onreadystate mit dem httpRequest Objekt füttern. Ganz simpel.

noch universeller, wäre eine Factoryfunktion, der du den Knoten übergibst oder eine in der du die ID ermittelst anhand des Response Objekt. Die Möglichkeiten sind vielfältig.

Struppi.

[hotti]

B Muss die callback() zum Dokument passend machen. Eine 'Universelle' callback() zu Schreiben ist relativ aufwändig.

Nein, ist es nicht.

var calback = function(response) {

var out = document.getElementById('out');
if(out) out.innerHMTL = response.innerText;
}

  
Ausgezeichnet, danke Dir!!!  
  

> und die Funktion musst du onreadystate mit dem httpRequest Objekt füttern. Ganz simpel.  
  
Das ist eine Möglichkeit, auf den Buffer zu verzichten. Ja, die Möglichkeiten sind vielfältig. Mit meinem mittlerweile SELFst erworbenen Verständns für  
  
xhr.onreadystatechange = callback;  
  
ist es mir nun auch möglich, über einen Puffer, das ist bei mir ein Object, die callback-Funktion von einer Custom-Funktion zu trennen, womit ich eine callbackfunktion bekomme, die ich in meine alib einbinden kann. Verstehe onreadystatechange, hier ist die Response ja schon im Anmarsch. Wir müssen nur ein Momentchen warten, bis der Browser die gefressen hat.  
  
Ein hierzu fest eingebautes setTimeout("customWriteDoc()", 500) berücksichtigt also die Zeit, die der UA braucht, zum 'vollständigen' Empfang der Response, in meinem Fall zum Schreiben des Buffers. Obenstehende 500 Millisekunden heißt nicht "warte bis die Response zurückkommt", sondern heißt "warte bis die Response einverleibt ist".  
  
 <http://rolfrost.de/cgi-bin/alib.cgi> Guck mal rein wenn Du magst  
  
Schönen Sonntag,  
Rolf  

-- 
's schneit, na und!?

[Struppi]

Das ist eine Möglichkeit, auf den Buffer zu verzichten. Ja, die Möglichkeiten sind vielfältig. Mit meinem mittlerweile SELFst erworbenen Verständns für

xhr.onreadystatechange = callback;

genau so meine ich das nicht.

ist es mir nun auch möglich, über einen Puffer, das ist bei mir ein Object, die callback-Funktion von einer Custom-Funktion zu trennen, womit ich eine callbackfunktion bekomme, die ich in meine alib einbinden kann. Verstehe onreadystatechange, hier ist die Response ja schon im Anmarsch.

Nein und nochmals Neimn, er ist schon da.

Ein hierzu fest eingebautes setTimeout("customWriteDoc()", 500) berücksichtigt also die Zeit, die der UA braucht, zum 'vollständigen' Empfang der Response, in meinem Fall zum Schreiben des Buffers.

Das ist überflüssg.

http://rolfrost.de/cgi-bin/alib.cgi Guck mal rein wenn Du magst

Nicht beosnders, ich hatte dir doch mal meinen Entwurf für ein AJAX Objekt geschickt, da wird eher deutlich, wie ich das mit dem callback meinte. Hier machst du nichts anderes, als die Funktion die den Event empängt callback zu nennen. Das ist Murks.

Ich zeig dir mal das Prinzip der Callback Funktion, anahand deines Beispiels (wirklich schön ist das aber nicht)

function wriDoc(response){  
	var hash = readParse(response);  
	document.getElementById('r_name').innerHTML = hash.name;  
	document.getElementById('r_vname').innerHTML = hash.vname;  
	document.getElementById('r_ort').innerHTML = hash.ort;  
	if(aobj.errstr){  
		document.getElementById('ajaxhinweis').innerHTML = aobj.errstr;  
	}  
	document.getElementById('ajaxhinweis').innerHTML = aobj.response;  
}  
  
  
// wrap ajax request  
function tx(){  
	aobj.url = "/cgi-bin/alib.cgi";  
	aobj.params = readForm();  
	aobj.method = 'GET';  
	ajaxRequest(wriDoc); // Hier wird der callback übergeben  
}		  
// Request und Response  
function ajaxRequest(callback){  
	var xhr = mob();  
	if(!callback) callback = funciton() {};  
	  
	function receiver(){  
		if(xhr.readyState == 4){  
			if(xhr.status == 200){ callback(xhr.responseText;) }  
			else{ aobj.errstr = 'Server anwortet nicht'; }  
		}  
	}  
	  
	var url = aobj.url + '?' + aobj.params;  
	xhr.open("GET", url, true);  
	xhr.send(null);  
	xhr.onreadystatechange = receiver;  
	return true;  
}  

Struppi.

[hotti]

ist es mir nun auch möglich, über einen Puffer, das ist bei mir ein Object, die callback-Funktion von einer Custom-Funktion zu trennen, womit ich eine callbackfunktion bekomme, die ich in meine alib einbinden kann. Verstehe onreadystatechange, hier ist die Response ja schon im Anmarsch.

Nein und nochmals Neimn, er ist schon da.

Natürlich ist sie schon da. Es dauert aber ein paar Millisekunden, bis die Browserinternen Buffer geleert sind und Du darauf zugreifen kannst (1).

Ich zeig dir mal das Prinzip der Callback Funktion, anahand deines Beispiels (wirklich schön ist das aber nicht)

Aber ich kann es schöner machen. Wie Du siehst, hab ich schonmal ein Objekt für den ganzen Ajaxkrempel. Da hänge ich einfach die Funktion als Objektmethode dran und schon scheint die Sonne wieder ;-)

(1) Und ich hab ein bischen länger gebraucht, dass zu verstehen. Dafür weiß ich jetzt, wie lange das buffering dauert, ätsch!

Vielen Dank,
viele Grüße,
schönen Sonntag!

[Struppi]

ist es mir nun auch möglich, über einen Puffer, das ist bei mir ein Object, die callback-Funktion von einer Custom-Funktion zu trennen, womit ich eine callbackfunktion bekomme, die ich in meine alib einbinden kann. Verstehe onreadystatechange, hier ist die Response ja schon im Anmarsch.

Nein und nochmals Neimn, er ist schon da.

Natürlich ist sie schon da. Es dauert aber ein paar Millisekunden, bis die Browserinternen Buffer geleert sind und Du darauf zugreifen kannst (1).

Nein und nochmals Nein - du hast das Prinzip immer noch nicht verstanden. Du kannst in der Response Funktion sofort ohne Verzögerung auf den Inahlt zugreifen. Dein Code ist falsch!

Noch mal: Deine Callback Funktion ist keine Callback Funktion, sondern einfach die Eventfunktion, die onreadystate aufgerufen wird, ich habe dir aber bereits gezeigt wie es richtig geht.

Struppi.

[hotti]

Nein und nochmals Nein - du hast das Prinzip immer noch nicht verstanden. Du kannst in der Response Funktion sofort ohne Verzögerung auf den Inahlt zugreifen. Dein Code ist falsch!

Schreib Du erstmal selber einen Code, der Dir zeigt, dass Browser interne Buffer haben :-)

Noch mal: Deine Callback Funktion ist keine Callback Funktion, sondern einfach die Eventfunktion, die onreadystate aufgerufen wird, ich habe dir aber bereits gezeigt wie es richtig geht.

Und ich hab das längst fertig

Weißt Du, Struppi, Du bist ein lieber Kerl. Aber erklären kannst Du entweder nicht so gut, oder Du rückst nicht so gerne mit Informationen raus.

Herzliche Grüße,
Rolf

[Struppi]

Weißt Du, Struppi, Du bist ein lieber Kerl. Aber erklären kannst Du entweder nicht so gut, oder Du rückst nicht so gerne mit Informationen raus.

Weißt du Hotti, ich erkläre schon gut, nur du gehst nicht auf das ein, was ich dir versuche zu erklären, bzw. bist du nicht besonders hilfreich dir etwas zu erklären.

Ich hatte dir ein funktionierendes Beispiel gezeigt, das du völlig ignoriert hattest und weiter gemurkst und dann wirfst du mir dann Unfähigkeit vor dir etwas zu erklären.

Und hier im Thread waren es genau _deine_ fehlenden Informationen, die alles unnötig kompliziert gemacht hatten. Das Stichwort Buffer, ist hier völlig verkehrt. Du brauchst in deinem Fall keinen Buffer. Bis mal klar wurde, dass du das Prinzip nicht verstanden hast, waren wir schon einen ganzen Tag beschäftigt. Und jetzt willst du mir erzählen ich rücke nicht mit den Informationen raus? Na Danke :-(

Das was du jetzt hast ist auch noch gemurkse, aber ich habe gar keine Zeit dir das zu erklären. Dein Ansatz hat strukturelle Probleme und ich müßte dir  OOP erklären, wofür mir gerade die Muse fehlt, zumal ich dir ja bereits einen Entwurf für ein wiedervertbares und flexibles AJAX Objekt zugeschickt hatte.

Struppi.

[ChrisB]

Hi,

Weißt Du, Struppi, Du bist ein lieber Kerl. Aber erklären kannst Du entweder nicht so gut, oder Du rückst nicht so gerne mit Informationen raus.

*Du* schwafelst immer noch lieber viel prosaischen Mist, anstatt deine Probleme mal von Anfang an klar und nachvollziehbar zu beschreiben.
Und gegebene Erklärungen verstehst du nicht, weil du gerne auf den Irrwegen, auf denen du dich verrannt hast, beharrst.

MfG ChrisB

[hotti]

Und gegebene Erklärungen verstehst du nicht, weil du gerne auf den Irrwegen, auf denen du dich verrannt hast, beharrst.

Wer keine Irrwege geht, wird den Hype nicht verstehen, welchen er hinterherrennt, anstelle eigene Wege zu gehen ;-)

Ich hab hier schon sehr oft danke gesagt und ich sags auch gerne immer wieder.

Viele Grüße und Danke,
Rolf

[unknown]

Schreib Du erstmal selber einen Code, der Dir zeigt, dass Browser interne Buffer haben :-)

Natürlich haben die Browser interne Puffer. responseText ist z.B. so ein Puffer, in dem ist die Response gespeichert.
Aber würdest du mir mal versuchen zu erklären, von welchen Puffern du redest?

[dedlfix]

Hi!

Verstehe onreadystatechange, hier ist die Response ja schon im Anmarsch. Wir müssen nur ein Momentchen warten, bis der Browser die gefressen hat.

Du hast es anscheinend nicht verstanden. onreadystatechange sagt nur, dass sich readyState geändert hat. Und wenn du jetzt mal in die Dokumentation schaust, welche Status damit angezeigt werden, siehst du vielleicht auch, dass es einen gibt, der die abgeschlossene Übertragung anzeigt.

Lo!

[hotti]

Du hast es anscheinend nicht verstanden...

Was ICH verstehe, ist unwichtig solange Computer meinen Code verstehen.

Hotti