2010-12-28 8 views
7

Sto riscontrando un problema con un'applicazione Java JSF: in un determinato caso, un'azione dell'utente causa una richiesta HTTP Ajax che aggiorna l'interfaccia utente correttamente, ma immediatamente viene attivata una seconda richiesta, causando un secondo aggiornamento non corretto.Come posso scoprire quale Javascript causa una richiesta Ajax?

Come posso scoprire (preferibilmente utilizzando Firebug) dove viene attivata esattamente la seconda richiesta? C'è un sacco di codice JS framework minified, quindi non so dove posizionare i breakpoint. L'impostazione del gestore onsubmit del modulo su console.trace non è stata di aiuto, suppongo perché si tratta di richieste Ajax indipendenti.

risposta

5

Mentre provi i suggerimenti nel risposte, ho scoperto che Firebug ha già esattamente ciò di cui ho bisogno fuori dalla scatola: la scheda Console mostra tutte le richieste, e per le richieste Ajax mostra il numero di file e di riga in cui sono originate, che mi dice dove impostare il mio punto di interruzione ...

+0

non è implementato negli strumenti di sviluppo di Chrome? – eugene

+0

@eugene: molto probabilmente sì. –

+3

Grazie Michele. Per la cronaca, è nella scheda Rete - Iniziatore.passa il mouse sopra il link e mostrerà lo stack chiamante. – eugene

0

Utilizzando Firebug è possibile impostare Breakpoints on DOM (HTML) Mutation Events se si dispone di alcune modifiche HTML nell'aggiornamento dell'interfaccia utente.

+0

Ma ciò si innesca quando viene ricevuta la * risposta *, no? Devo scoprire da dove proviene * la * richiesta. –

+0

Ovviamente, ma si restringe dove puoi scegliere di avviare il debug. È anche possibile profilare la richiesta, la risposta, il ciclo di aggiornamento ui per restringere il punto in cui si trova l'attività. –

0

Se il framework astrae le richieste AJAX, dovresti essere in grado di tracciare le chiamate alle astrazioni. Ad esempio, jQuery consente questo attraverso il suo global AJAX event handlers.

Un altro modo più efficace per affrontare il problema sarebbe quello di eseguire replace the XHR object e tracciare le chiamate effettuate (ad esempio se il framework non fornisce l'astrazione di cui sopra o se le chiamate che si desidera utilizzare non utilizzano l'astrazione) . Basta sostituire lo GM_log con console.trace nello script alla fine della pagina e includerlo nella pagina che stai testando.

0

Quello che ho fatto personalmente in questi casi è l'utilizzo di un proxy HTTP che può mettere una richiesta o una risposta "in attesa". Per esempio. Burp Proxy(questo è in realtà uno strumento di sicurezza, ma funziona perfettamente a scopo di debug)

Avviare il proxy e configurare il browser per utilizzarlo. Passare alla pagina da cui provengono le richieste roque e attivare le richieste di intercettazione (questo potrebbe richiedere un po 'di pratica in quanto Burp Proxy può essere uno strumento piuttosto complicato).

Ora fai l'azione dell'utente, se tutto va bene il proxy lo intercetta e aspetta che la tua conferma lo faccia passare. Fai questo. Quindi probabilmente vedrai arrivare la seconda richiesta e anche essere intercettata dal proxy. Non lasciar passare questo, ma passa a Firebug e sospendi nel debugger. Spero che sarai in grado di vedere da dove proviene. Modifica: ripensandoci, la natura asincrona di AJAX probabilmente significa che non sarai in grado di vedere quale sia esattamente il punto tramite questo metodo ... :(

Almeno puoi anche configurarlo per intercettare le risposte. Entrambe le richieste e le risposte possono essere modificati al volo, che può essere grande per la sperimentazione e il debug e potrebbe aiutare a restringere il problema.

0

potrebbe ciò contribuirebbe, chiamante è un metodo in oggetto Function di JavaScript.

console.log (arguments.callee.caller.toString());

Problemi correlati