Oggetto XHR globale

ZER0 <zer0.shock (AT) libero (DOT) it> ha scritto:

ma il bello deve ancora venire, se si lancia l'abort() l'oggetto va in
readyState = 4 (il chè potrebbe avere anche senso) pero' sollevando
un'eccezione meravigliosa

Non è questo che solleva un'eccezione. Scritta in questo modo, la tua
è un'affermazione errata.

Quoto!

terminata "normalmente", infatti la proprietà status in questo caso non è
accessibile similmente agli stati intermedi di cui si parlava prima

Se mi dici queste cose, ti consiglio davvero una lettura approfondita
alla reference dell'oggetto XMLHttpRequest di Gecko.

Ti rinnovo anche il mio consiglio di cercare sul newsgroup, visto che
questa problematica fu discussa già in passato, e anche in modo molto
approfondito, se la mia memoria non m'inganna.

Se non ricordo male, ne parlammo anche tu ed io all'epoca della mia chat,
ricordi? Il punto è, se non erro, che in caso di terminazione forzata della
richiesta xhr firefox passa direttamente allo stato 4 senza passare per gli
stati intermedi (ad esempio, direttamente da 2 a 4) e non è possibile
accedere alla proprietà status. La cosa ha senso, del resto, giacché non ha
senso parlare di "status" (ovverosia, in sostanza, dello stato della
*risposta* ottenuta) quando la richiesta stessa è stata abortita e dunque
risposta non v'è; è altresì ragionevole che il readystate valga 4, poiché
in effetti lo stato della *richiesta* è "completato".

Mi pare

--
Nando [?]
Apostolo della Prova

Nando <aarrmmaaccoott (AT) libero (DOT) it> wrote:

[cut]

Ti rinnovo anche il mio consiglio di cercare sul newsgroup, visto che
questa problematica fu discussa già in passato, e anche in modo molto
approfondito, se la mia memoria non m'inganna.

Se non ricordo male, ne parlammo anche tu ed io all'epoca della mia chat,
ricordi?
[cut]

Lo ricordo più che bene, ma volevo che Ugo s'impegnasse un minimo nella
ricerca sul newsgroup.

Il punto è, (..) Mi pare

Questo lo so io, lo sai tu, e se lui ci fosse arrivato allo stesso modo
in cui l'hai fatto te (anche aiutandosi tramite google ed il precedente
thread, ma traendo da solo le sue conclusioni) sarebbe stato meglio.

Soprattutto viste le successive lacune che ho notato su dei passaggi.

Ormai dovresti saperlo bene quanto me, che ciò che maggiormente conta è
"come" si raggiunge una certa conoscenza, e non la conoscenza in sé.

--
"Se c'è qualcosa di più importante del mio ego su questa nave,
la voglio catturata e fucilata."

ZER0 <zer0.shock (AT) libero (DOT) it> ha scritto:

Nando <aarrmmaaccoott (AT) libero (DOT) it> wrote:

[cut]
Ti rinnovo anche il mio consiglio di cercare sul newsgroup, visto che
questa problematica fu discussa già in passato, e anche in modo molto
approfondito, se la mia memoria non m'inganna.

Se non ricordo male, ne parlammo anche tu ed io all'epoca della mia chat,
ricordi?
[cut]
Lo ricordo più che bene, ma volevo che Ugo s'impegnasse un minimo nella
ricerca sul newsgroup.

Il punto è, (..) Mi pare

Questo lo so io, lo sai tu, e se lui ci fosse arrivato allo stesso modo
in cui l'hai fatto te (anche aiutandosi tramite google ed il precedente
thread, ma traendo da solo le sue conclusioni) sarebbe stato meglio.

Soprattutto viste le successive lacune che ho notato su dei passaggi.

Ormai dovresti saperlo bene quanto me, che ciò che maggiormente conta è
"come" si raggiunge una certa conoscenza, e non la conoscenza in sé.

Sono sempre stato irruente e frettoloso :-S

--
Nando [?]
Apostolo della Prova

Da una lettura veloce, mi sembra che tu sia abbastanza fuori strada..

Ma chiediti questo: cos'è lo status? A cosa si riferisce la proprietà
omonima? Cos'è il readystate?

Effettivamente hai fatto bene a farmi interrogare, solo che adesso che l'ho
fatto e ho cercato di approfondire ulteriormente i temi in questione,
continuano a non essermi chiare delle cose...

E quando viene invocato l'evento onreadystatechange? Gli unici motivi
per cui tu sia fuori strada, è che non ti sei risposto a domande come
queste.

un'idea me l'ero fatta e credevo fosse sufficiente...

Leggiti la reference dell'oggetto XMLHttpRequest, se hai dei dubbi.

ok, mi sono riguardato in particolare:
http://developer.mozilla.org/en/docs/XMLHttpRequest
http://developer.mozilla.org/en/docs...XMLHttpRequest
http://developer.mozilla.org/en/docs/nsIXMLHttpRequest

per FF gli stati intermedi allo 0 (uninitialized) e al 4 (complete) sono
sacri, cioè tentativi di leggere lo status,
rispedire header di un nuovo
messaggio e/o sperirlo proprio, lo fanno andare in errore

No, non direi proprio. E c'è anche un post recentissimo che smentisce
questa tua affermazione.

io ho fatto le seguenti prove:
sull'onreadystatechange e su tutti gli readyState < 4 se ritento di settare
dei RequestHeader o di invire un nuovo messaggio con lo stesso oggetto XHR,
FF mi va in errore
invece lo status dopo che readyState è passato a 1 è accessibile.

Fa eccezzione il caso di interruzione forzata dell'esecuzione richiamando
abort(), readyState assume il valore 4 e:
nel primo caso (cioè ritentare un send...) effettivamente non va in errore
FF, va in errore la richiesta sucessiva evocando anche l'eventuale onerror
settato,
nel secondo (leggere lo status) va in errore FF, perchè come immaginavo e
come mi è stato confermato in questi ultimi post, lo stato della risposta
non è avviabile perchè risposta non c'è stata...

ma il bello deve ancora venire, se si lancia l'abort() l'oggetto va in
readyState = 4 (il chè potrebbe avere anche senso) pero' sollevando
un'eccezione meravigliosa

Non è questo che solleva un'eccezione. Scritta in questo modo, la tua
è un'affermazione errata.

mmmm, se è più corretta come l'ho detto prima bene, altrimenti credo di non
avere ancora capito

Ti rinnovo anche il mio consiglio di cercare sul newsgroup, visto che
questa problematica fu discussa già in passato, e anche in modo molto
approfondito, se la mia memoria non m'inganna.

mah, io sin da subito avevo trovato quel 3d in cui tu e Nando parlavate
della sua chat, ma non mi era sembrata particolarmente illuminante per
quanto concerne questa mia problematica, cmq ieri sera mi sono letto tutti
i 50 post di quel 3d e devo dire che è stata una lettura interessante, però
non mi ha tolto i dubbi e gli errori logici che sto commettendo
sarò duro di comprendonia

ciao
aspetto le tue correzioni
fiducioso che tu mi dia anche 2 righe di codice :P

Codice per cosa? Qui il problema è di conoscenza e di logica, non vi
è alcun codice da scrivere, c'è solo da capire.

sperando di avere fatto qualche passo in avanti (altrimenti mi sparo -
visto il tempo che mi sta facendo perdere questa cosa), mi potresti
spiegare il perchè del fallimento della seconda richiesta:


var xmlhttp = new XmlHttpRequest( );

xmlhttp.open( "GET", '...', true );
xmlhttp.setRequestHeader( ... );
xmlhttp.send( null );

xmlhttp.abort( );

xmlhttp.open( "GET", '...', true );
xmlhttp.onerror = function (e)
{
try
{
alert( e.target.readyState )
alert( e.target.status )
}
catch( e )
{
alert(e);
}
}
xmlhttp.setRequestHeader( "..." );
xmlhttp.send( null );


Evocando l'abort della prima richiesta, mi sono accorto che l'ogetto cambia
il readyState a 4 e quindi viene evocato l'onreadystatechange (che per
semplicita non ho gestito), perchè cmq l'operazione è completata (e mi sta
bene, sono d'accordo, l'abbiamo già detto
Quello che non capisco è perchè mi fallisce quella immediatamente
sucessiva, come se l'oggetto fosse ancora in una fase di interruzione delle
richieste, come se facessi troppo veloce e lui non avesse ancora finito con
la precedente...
A questo punto allora ho provato a lancira la seconda richiesta solo dopo
che viene evocato l'onreadystatechange della prima e in questo caso mi
sembra che vada a buon fine - questo sembrerebbe avalorizzare le mie
ipotesi ma io rischio e mi gioco il gioielli di famiglia e scometto che
sono ancora in alto mare
in fine alto mare per alto mare, ho tentato di lanciare la seconda
richiesta ritardandola con un setTimeout e anche in questo caso sembrerebbe
andare a buon fine (anche con 0ms - è bastato decontestualizzarla),
premesso che questa non la ritengo una soluzione, mi piacerebbe capire
meglio che cosa succede, io mi sono arenato e oltre non rieso ad andare

Pensaci tu, please

On Sun, 9 Dec 2007 12:07:18 +0100, Ugo wrote:

per FF gli stati intermedi allo 0 (uninitialized) e al 4 (complete) sono
sacri, cioè tentativi di leggere lo status,
rispedire header di un nuovo
messaggio e/o sperirlo proprio, lo fanno andare in errore

No, non direi proprio. E c'è anche un post recentissimo che smentisce
questa tua affermazione.

io ho fatto le seguenti prove:
[..]

E quindi dovresti esserti smentito da solo.
In ogni caso, non fare troppo affidamento al fatto che lo status sia
accessibile dopo che il readyState è passato a 1; se ti sei letto il
thread di cui parlavamo io e Nando dovresti averlo capito.

Fa eccezzione il caso di interruzione forzata dell'esecuzione richiamando
abort(), readyState assume il valore 4 e:
[cut]

Stai facendo un po' di miscuglio tra i problemi che ha il tuo codice
originale e i vari comportamenti di XMLHttpRequest su Firefox.

Risolvi una cosa per volta.

nel secondo (leggere lo status) va in errore FF, perchè come immaginavo

L'avrai anche immaginato, ma non è quello che hai scritto.
L'eccezione viene sollevata perché tenti di accedere allo status che
non è mai giunto. Non è l'abort() a farlo. Ti è chiaro questo, ora?

ma il bello deve ancora venire, se si lancia l'abort() l'oggetto va in
readyState = 4 (il chè potrebbe avere anche senso) pero' sollevando
un'eccezione meravigliosa

Non è questo che solleva un'eccezione. Scritta in questo modo, la tua
è un'affermazione errata.

mmmm, se è più corretta

Non è una questione di "più"; l'affermazione di prima non era "poco"
corretta, era proprio sbagliata.

mah, io sin da subito avevo trovato quel 3d in cui tu e Nando parlavate
della sua chat,

E allora mi chiedo come mai hai perseverato nell'errore, soprattutto
nel tuo codice.

quanto concerne questa mia problematica,

In quel thread (e anche in questo ormai), c'era scritto il perché il
tuo codice andava in errore:

<news:leg16a1lo8cb.tim0nivvhw1c.dlg (AT) 40tude (DOT) net>

Ora ti dovrebbe essere palese il perché fare questo:

if( xmlhttp.readyState == 4 )
{
if( xmlhttp.status == 200 )
callback( xmlhttp.responseText );
else
alert( "Error; status = " + xmlhttp.status );
}

E' un errore.

sperando di avere fatto qualche passo in avanti (altrimenti mi sparo -
visto il tempo che mi sta facendo perdere questa cosa), mi potresti
spiegare il perchè del fallimento della seconda richiesta:

Questo è un problema di tutt'altra natura, difatti non ottieni alcun
errore (a meno che tu non vada a chiedere lo status, appunto, quando
non ne hai).
In IE quando invochi il metodo "open" viene reinizializzato tutto, è
questo il motivo (che spero tu sappia) del perché gli eventi vengono
impostati DOPO l'open, e ogni volta che viene chiamato.
Su Firefox no, l'onreadystate potresti anche impostarlo prima e solo
una volta.
Se lo imposti prima dell'open della prima richiesta, noterai come la
funzione venga chiamata anche per i metodi "open", per esempio.

Il punto è che essendo un oggetto così condiviso e facendo richieste
asincrone, non dai il tempo all'engine di reimpostare le risorse. In
IE il problema non si pone perché viene eliminato a monte.

Nel thread di Nando comunque, si parla anche di problemi come questi
e di come discriminare le chiamate avvenute con successo; sebbene il
contesto fosse un poco diverso (cambio pagina e onunload mi pare, ma
se hai letto recentemente tutto il thread te lo ricorderai meglio di
me, ma il comportamento è il medesimo).

Con un approccio OOP riesci a risolvere elegantemente il tutto.

--
~ "Gesù ha avuto la sfortuna che su quello che ha detto ci hanno
costruito sopra una religione."
(Josè Saramago)

[cut]

In ogni caso, non fare troppo affidamento al fatto che lo status sia
accessibile dopo che il readyState è passato a 1;

mi sono sbagliato o cmq volevo dire >1
come dice chiaramente una delle reference MDC:
2 LOADED send() has been called, headers and status are available.

[cut]

L'eccezione viene sollevata perché tenti di accedere allo status che
non è mai giunto. Non è l'abort() a farlo. Ti è chiaro questo, ora?

direi di sì,
cmq è l'abort() a causare l'interruzione e quindi a non far "giungere" lo
status... e a questo punto mi sorge un dubbio tremendo, ci sono altre
circostanze in cui il status non perviene nonstante il readyState sia >1?
Mi sembra che ragionevolmente il caso di timeout del browser nel caso di
grossa richiesta (o estrema lentezza di connesione e/o mix dei 2), potrebbe
rientrare in questa casistica, pero' giusto di recente mi sembra di aver
provato e di aver constatato che venisse settato a 200 come se niente
fosse...

[cut]

Ora ti dovrebbe essere palese il perché fare questo:

if( xmlhttp.readyState == 4 )
{
if( xmlhttp.status == 200 )
callback( xmlhttp.responseText );
else
alert( "Error; status = " + xmlhttp.status );
}

E' un errore.

direi di sì, oltre il controllo del readyState prima di poter accedere allo
status devo essere sicuro che questo sia avviabile, ma questo mi riporta
alla domanda che ho posto precedentemente, il caso di abort() si puo'
gestire in qualche modo, ma ci possono essere anche altri casi?

Questo è un problema di tutt'altra natura, difatti non ottieni alcun
errore (a meno che tu non vada a chiedere lo status, appunto, quando
non ne hai).
In IE quando invochi il metodo "open" viene reinizializzato tutto, è
questo il motivo (che spero tu sappia)

beh, ora mi è più chiaro

del perché gli eventi vengono
impostati DOPO l'open, e ogni volta che viene chiamato.
Su Firefox no, l'onreadystate potresti anche impostarlo prima e solo
una volta.
Se lo imposti prima dell'open della prima richiesta, noterai come la
funzione venga chiamata anche per i metodi "open", per esempio.

in effetti, avevo fatto un test...

Il punto è che essendo un oggetto così condiviso e facendo richieste
asincrone, non dai il tempo all'engine di reimpostare le risorse. In
IE il problema non si pone perché viene eliminato a monte.

ecco questa parte, un po' più delicata non mi è chiarissima, ma è uguale,
sei già stato fin troppo paziente

Nel thread di Nando comunque, si parla anche di problemi come questi
e di come discriminare le chiamate avvenute con successo;

andro' a rileggere, non mi sembrava...

[cut]

Con un approccio OOP riesci a risolvere elegantemente il tutto.

dai vedro' cosa riesco a fare...

On Wed, 12 Dec 2007 00:15:41 +0100, Ugo wrote:

In ogni caso, non fare troppo affidamento al fatto che lo status sia
accessibile dopo che il readyState è passato a 1;

mi sono sbagliato o cmq volevo dire >1
come dice chiaramente una delle reference MDC:
2 LOADED send() has been called, headers and status are available.

Ugualmente sbaglieresti a farci troppo affidamento. Hai detto che hai
letto tutto il thread tra me e Nando. Là è scritto chiaramente.
E tra l'altro se hai fatto un poco di debug dovresti averlo notato da
te.

[cut]

L'eccezione viene sollevata perché tenti di accedere allo status che
non è mai giunto. Non è l'abort() a farlo. Ti è chiaro questo, ora?

direi di sì,
cmq è l'abort() a causare l'interruzione e quindi a non far "giungere" lo
status...

No, non è vero. Se usi l'abort(), ma attendi la reinizializzazione da
parte dell'oggetto, il problema non si verifica. Inoltre se hai letto
il famoso thread, hai visto come la medesima problematica si ha anche
in altri casi, senza che l'abort() venga utilizzato.

La tua affermazione sarebbe vera se solo con l'abort() si verificasse
sempre questo comportamento.

e a questo punto mi sorge un dubbio tremendo, ci sono altre
circostanze in cui il status non perviene nonstante il readyState sia >1?

A me invece, sorge il "dubbio tremendo" che il thread in questione tu
non l'abbia letto.. almeno, non con attenzione.
Anche la risposta a questa domanda la trovi chiaramente scritta li.

[cut]

direi di sì, oltre il controllo del readyState prima di poter accedere allo
status devo essere sicuro che questo sia avviabile, ma questo mi riporta
alla domanda che ho posto precedentemente, il caso di abort() si puo'
gestire in qualche modo, ma ci possono essere anche altri casi?

Si, ce ne possono essere anche altri.
Attualmente, che io sappia, la cosa migliore è attuare l'approccio di
cui si è parlato io e Nando.

Il punto è che essendo un oggetto così condiviso e facendo richieste
asincrone, non dai il tempo all'engine di reimpostare le risorse. In
IE il problema non si pone perché viene eliminato a monte.

ecco questa parte, un po' più delicata non mi è chiarissima,

In IE, un "open" resetta completamente l'oggetto; in Gecko no, tant'è
che mantiene tutta una serie di riferimenti interni e di script (come
si può vedere dall'onreadystatechange, di cui ti ho parlato prima).
Se non dai tempo all'oggetto XMLHttpRequest di reimpostare le risorse
interne, ottieni un comportamento anomalo.
Probabilmente la cosa migliore sarebbe rendere "sincrono" l'abort, in
modo che non vi siano sovrapposizioni interne.
Ma dato che non mi sono messo a spulciare il codice sorgente di Gecko
lascio ai programmatori il beneficio del dubbio.

Nel thread di Nando comunque, si parla anche di problemi come questi
e di come discriminare le chiamate avvenute con successo;

andro' a rileggere, non mi sembrava...

Leggi, leggi.

Con un approccio OOP riesci a risolvere elegantemente il tutto.

dai vedro' cosa riesco a fare...

Bravo... Se questo thread fosse anche solo riuscito a spronarti a uno
sviluppo più OOP, avrebbe già fatto tanto.

--
~ Plagiarism is copying from one source;
research is copying from two or more
(Wilson Mizner)

Bravo... Se questo thread fosse anche solo riuscito a spronarti a uno
sviluppo più OOP, avrebbe già fatto tanto.

Ma sì, un po' l'ha fatto
Ora ti farò un breve resoconto delle mie evoluzioni:
ho creato un oggetto che vuole in qualche modo "estendere" l'oggetto
XMLHttpRequest, cercando di introdurre una sorta di gestione degli errori e
dell'abort alla IE e semplificando un po' le procedure di richiesta delle
pagine.
L'idea è che si istanzi uno solo di questo oggetto (introducendo un domani
anche il concetto di Singleton) al momento attraverso una variabile
globale.
Ho preso spunto dai tanto citati post e ho implementato la cosa cercando di
rendere sicuro l'accesso allo status della risposta tenedo memoria degli
readyState che si susseguono e considerando buono solo quello che vale 4 la
cui versione salvata invece valga 3, e inoltre ho introdotto il concetto di
coda ad un solo elemento che è ottima per eliminare subito eventuali
richieste pendenti a causa di lentezze del server e utile se non necessaria
per l'autorichiesta a seguito di un abort dovuto alla sovrapposizione di
una richiesta pendente (boh chissa cosa ho detto), ed credo che sia
fondamentale se si vuole attendere che il browser concluda le eventuali
operazioni dopo la ricezione della pagina...

Comunque ti posto un po' quello che ho realizzato, non considerare per il
momento tutte le chiusure che ho introdotto, poi metteremo a posto anche
quelle e nemmeno altre ottimizzazioni secondarie che si possono fare,
quello che mi interessa sono gli errori concettuali che sto facendo...
perchè non ho avuto modo di indagare ma con IE riscontro un problema al
tentativo di richiesta multipla, ho preferito inviare il codice così com'è
in modo che domani lo potessi vedere...


function myXmlHttpRequest( )
{
this.xmlhttp = getXmlHttpRequest( );

this.lastReadyState = 0;
this.req = null;
}
myXmlHttpRequest.prototype.onReadyStateChange =
function( callbackOnSuccess, callbackOnError )
{
var self = this;

return function( evt )
{
if( self.xmlhttp.readyState == 4 )
{
if( self.lastReadyState == 3 )
{
if( self.xmlhttp.status == 200 )
{
if( typeof callbackOnSuccess == 'function' )
{
self.executingCallback = true;
callbackOnSuccess( self.xmlhttp.responseText );
self.executingCallback = false;
}
}
else
{
alert( "Unexpected status: " + self.xmlhttp.status );
if( typeof callbackOnError == 'function' )
{
self.executingCallback = true;
callbackOnError( );
self.executingCallback = false;
}
}
}
else
{
// alert( "Unexpected lastReadyState on ReadyState = 4: " +
self.lastReadyState );
if( typeof callbackOnError == 'function' )
{
self.executingCallback = true;
callbackOnError( );
self.executingCallback = false;
}
}

self.lastReadyState = 0;

if( self.req )
{
var req = self.req;
self.req = null;
self.request( req );
}
}
else
{
self.lastReadyState = self.xmlhttp.readyState;
}
}
}
myXmlHttpRequest.prototype.request = function( req )
{
if( ! req )
return;

switch( req.type )
{
case 'async_get':
{
this.xmlhttp.open( "GET", 'index.php?s=' +
( new Date( ) ).getTime( ) + Math.random( ) + '&' +
req.query, true );
break;
}
case 'async_post':
{
this.xmlhttp.open( "POST", 'index.php?s=' +
( new Date( ) ).getTime( ) + Math.random( ) + '&' +
req.query, true );
break;
}
}

this.xmlhttp.setRequestHeader( "If-Modified-Since",
"Sat, 11 Jan 1977 00:00:00 GMT" );

if( ! req.type.indexOf( 'async' ) )
this.xmlhttp.onreadystatechange =
this.onReadyStateChange( req.callbackOnSuccess,
req.callbackOnError );

this.xmlhttp.send( null );

}
myXmlHttpRequest.prototype.getRequest = function( type, query,
callbackOnSuccess, callbackOnError )
{
var req = { 'type' : type, 'query' : query,
'callbackOnSuccess' : callbackOnSuccess,
'callbackOnError' : callbackOnError };

if( this.lastReadyState == 0 )
{
this.request( req );
}
else
{
this.req = req;
if( ! this.executingCallback )
this.xmlhttp.abort( );
}
}



usata cad es. così:

var http = new myXmlHttpRequest( );
function fun( )
{
http.getRequest( 'async_get', 'page=test_sleep',
function(txt){alert(txt);} );
}

<a href="#" onclick="fun();return false">req</a>

cut

ho preferito inviare il codice così com'è
cut

Non mi parli più

On Fri, 21 Dec 2007 01:31:08 +0100, Ugo wrote:

ho preferito inviare il codice così com'è
cut

Non mi parli più

Sinceramente non mi sembrava che il post in sé necessitasse di una
risposta; non mi pare che vi siano domande o altro. Inoltre, tutto
ciò che doveva esser detto sull'argomento è già stato fatto, qui o
nell'altro thread. Il resto sta a te.

Un piccolo appunto: non usare "self" come nome di variabile, viene
già usato dal browser come sinonimo di window.

--
~ Se cerchi una mano disposta ad aiutarti,
la trovi alla fine del tuo braccio.