Topic: script defer: esiste qualcosa di equivalente?

[ilpapabuono]

Ho recentemente provato a sperimentare AJAX; durante numerosi test e debugging ho trovato quello che mi sembra un buco nell'implementazione javascript di firefox - non so se questo è il forum giusto, spero di si.

In poche parole: se durante una sessione AJAX l'html caricato "dinamicamente" (tramite innerHTML, non DOM) deve essere utilizzato per ulteriori operazioni dinamiche (es getElementById()), l'HTML AJAX-injected non risulta "visibile" al codice javascript AMENOCHE' non venga "acceso" un alert('qualche testo') subito dopo il caricamento. Questa operazione sembra in qualche modo "dare una scrollata" a firefox che - successivamente - "prende in carico" il codice HTML e lo rende disponibile al codice javascript.
In MSIE viene detto esplicitamente che per utilizzare del Javascript iniettato bisogna mettere "DEFER" nella sua dichiarazione. Ed in effetti (anche se non nel 100% dei casi) in IE tale tecnica funziona. Come fare in Firefox? Qualcuno sta "badando" a questa carenza?

[the fly on the net]

Non mi è affatto chiaro quello che hai scritto.

Presumo, ma non ne sono sicuro, che tu stia tentando di usare gli oggetti dHTML prima che siano caricati in memoria: in questo caso dovresti eseguire tale codice a seguito dell'evento window.onload

Per chiarezza, in Explorer gli script con l'attributo defer vengono eseguiti alla fine del caricamento della pagina - questo secondo molti è un comportamento errato di Explorer stesso.
Le raccomandazioni W3C dicono solo che gli script con defer non producono output HTML (ovvero non contengono alcun document.write).
Esiste una discussione su bugzilla a riguardo, secondo la quale i programmatori di Mozilla sono orientati a mantenere il comportamento attuale in quanto più aderente agli standard ed in futuro di usare tale attributo solo come ottimizzazione per le performance.

[ilpapabuono]

Si mi rendo conto che il problema non è facile da spiegare.
In pratica: usando codice ajax, all'interno di un <DIV id="pippo"> viene iniettato, tramite l'attributo innerHTML  - recentemente inserito anche in Firefox, per la sua utilità immagino - dell'HTML.
L'operazione finale (che avviene DOPO il caricamento e con stato 4: tutto ok) consiste nel far "girare" una routine javascript - chiamiamola "giuseppe()" - la quale va ad operare proprio sull'HTML appena caricato.
Quel che avviene è che il javascript non VEDE l'html appena caricato: un getElementById() restituisce valore nullo, nonostante quell'id esista, e nonostante nelle specifiche venga scritto che, all'atto del caricamento in innerHTML, viene effettuato anche il parsing e la corretta costruzione del DOM relativo al nuovo html appena iniettato.
La cosa curiosa che ho notato - e che speravo interessasse - è che se tra caricamento e funzione javascript interpongo un alert("qualcosa"), tutto funziona.
Ciò mi ha fatto pensare al fatto che è necessario dare un po' di tempo a un qualche thread perchè completi il parsing prima di effettuare operazioni sull'HTML stesso.
A me non serve affatto il DEFER: mi serve qualcosa (un workaround forse) che non mi obblighi ad usare l'alert in questione. Un wait()? Come sai purtroppo in javascript non si può fare. Inoltre giuseppe() ha bisogno di un parametro, per cui non posso usare setTimeout().
Il discorso, curiosamente, è identico sia per FF che per IE. Solo che, sotto IE, se organizzo in modo leggermente diverso la chiamata di giuseppe() e ci metto DEFER, le cose vanno. Tutto qui. Non ho bisogno che tu mi ribadisca che IE è una schifezza: dopo 15 anni di programmazione HTML, javascript, php, css, XML, XSL, mi sono fatto un'idea
Ho letto in un altro forum che l'implementazione di innerHTML sotto FF è stata un po' frettolosa e incompleta. Segnalo solo che effettivamente mi sembra sia così. Puoi indicarmi un possibile workaround? Esiste una variabile di stato che mi segnali il completamento del PARSING e della costruzione del DOM? O c'è proprio un errore nell'implementazione di innerHTML?

[the fly on the net]

Ho sempre cercato di evitare nei miei script, sia AJAX che non, per quanto possibile l'uso di innerHTML per la sua natura non-standard.

In ogni caso, ho fatto delle prove e non riscontro affatto quello che dici: in seguito ad una chiamata a XmlHttpRequest, inserisco del codice tramite innerHTML ed immediatamente dopo leggo l'id del nuovo oggetto senza problemi.

Qui vedi la mia prova:
http://www.flyonthenet.com/test/innerHTML.html

[ilpapabuono]

Sei stato molto gentile a darmi uno script di prova. Vedrò di capirlo bene e lavorarci su.
Purtroppo - per noi comuni mortali, evangelizzati sì, ma che dobbiamo vivere della pagnotta quotidiana - gli script devono funzionare sia su FF che su IE, e questo è il solo lato negativo della tua soluzione.
Spero di poterti dare presto una pagina di prova di quanto affermo, ma per ora il tutto è in un'applicazione intranet e non ho potere di dartene l'accesso.
Ti ringrazio comunque dell'attenzione.

[the fly on the net]

Vedrò di capirlo bene e lavorarci su.
Purtroppo - per noi comuni mortali, evangelizzati sì, ma che dobbiamo vivere della pagnotta quotidiana - gli script devono funzionare sia su FF che su IE, e questo è il solo lato negativo della tua soluzione.

Lo script di prova *volutamente* non funziona su Explorer
A me è interessato solo dimostrare la funzionalità con Firefox.

[ilpapabuono]

Certo che come evangelizzatore sei un pelo gesuita
Ho provato a copiare il tuo script da me, modificando la chiamata
HttpRequest.open("GET", "innerHTML.aspx", true);
con
HttpRequest.open("GET", "provajax.php", true);
Quest'ultimo restituisce un piccolo brano di xhtml. Ho provato sia con che senza intestazioni HTML.
Il debugger si ferma affermando che
"HttpRequest.responseXML has no properties"
Che caratteristiche deve avere "provajax.php" - che caratteristiche ha innerHTML.aspx?
La differenza fondamentale tra il tuo e il mio script è che tu usi l'attributo "responseXML" mentre io uso "responseTxt"; il resto è sostanzialmente identico. Inoltre - e se hai pazienza ti inviterei a fare una prova - il mio problema si è riscontrato con un chunk HTML molto più grande (un albero DOM molto più complesso).
Se - come mi sembra - il problema dipende dal tempo, la tua prova potrebbe non essere esaustiva. Ti ricordo che se faccio girare il mio script tramite debugger, o ci metto un alert("speta!") in mezzo - ossia con MOLTA calma - tutto funziona perfettamente; il che sembrerebbe indicare che non ci sono errori di logica.

A parte una certa supponenza da sauro adulto nei confronti di un girino, sei comunque molto gentile.

[ilpapabuono]

OK usando responseText (non Txt!) anzichè responseXML funziona adesso.
Mi dici qual'è la parte "non IE compliant" ?
Sul maledetto continua a non funzionare.
Immagino sia:
   HttpRequest.onreadystatechange = HttpRequestReadyState;

o no?

[ilpapabuono]

Ce l'ho fatta!  Ho trovato un modo per dare un timeout (non sapevo che setTimeout accetta anche una stringa contenente una chiamata a funzione con parametro) e tutto va a meraviglia.
Confermo che ci vuole un certo tempo perchè il DOM venga preso in carico (dipendentemente dalla complessità del chunk HTML in oggetto) dopo che a un elemento del DOM stesso si è appeso l'HTML tramite la funzione innerHTML.
Spero che questo possa servire a qualcuno, magari agli sviluppatori di Mozilla.

Scusa se ti ho fatto perdere del tempo, ma mi pare che l'informazione non sia irrilevante.

L'applicazione in oggetto - spero ti interessi - è un Nested Ajax Tabs (vedi su DynamicDrive.com per l'applicazione base Ajax Tabs). Cliccando su un TAB si ottiene un chunk contenente ulteriori sub-TAB, i quali - cliccati - possono contenerne altri e via dis(ri-)correndo.

Funziona!

[the fly on the net]

Il debugger si ferma affermando che
"HttpRequest.responseXML has no properties"

Significa che probabilmente il codice restituito dal server non è XML (tipo mime text/xml) oppure che il codice XML contiene errori (non è well-formed)
Anche se è codice XHTML, fornendolo come XML al client puoi usare responseXML.

Il vantaggio è che responseXML è un oggetto DOM e puoi usare i metodi classici del DOM, tipo getElementsByTagName, childNodes, ecc, mentre responseText è una semplice stringa di testo.

il mio problema si è riscontrato con un chunk HTML molto più grande (un albero DOM molto più complesso).
Se - come mi sembra - il problema dipende dal tempo, la tua prova potrebbe non essere esaustiva.

E' da provare, ma probabilmente responseXML essendo già un oggetto DOM è più performante quando lo sia aggiunge al DOM dell'HTML.
Come già detto non uso innerHTML per Firefox, ma ho già lavorato con XML grossi ed usando appendChild o replaceChild non ho mai avuto problemi.

Mi dici qual'è la parte "non IE compliant" ?

Non saremmo nel forum giusto, qui si parla di Mozilla, comunque in Explorer gli oggetti responseXML la proprietà .innerHTML si chiama .xml, questo perché anche usando il namespace XHTML, Explorer non lo riconosce come HTML (bug presente anche nella beta di IE7).