How do you debug an Ajax call?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

How do you debug an Ajax call?

Thelliez
Maybe I set something wrong, but I cannot figure out where to find
debug info when a Jquey/Ajax call dies.  The usual logs are not
showing anything.

I am behind Apache/FastCGI (using something similar to what James had
documented).  The factcgi instance logs, the gemstone/s logs and the
OS logs are all not showing anything.

The only thing I see is a 505 with firebug.


Is that expected?

Thanks,
Thierry
Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

James Foster-8
Is there anything in the "Object Log"? The Object Log is available from GemTools, Jade, and the tools link in the default Seaside implementation.

James

On May 12, 2011, at 9:33 AM, Thierry Thelliez wrote:

> Maybe I set something wrong, but I cannot figure out where to find
> debug info when a Jquey/Ajax call dies.  The usual logs are not
> showing anything.
>
> I am behind Apache/FastCGI (using something similar to what James had
> documented).  The factcgi instance logs, the gemstone/s logs and the
> OS logs are all not showing anything.
>
> The only thing I see is a 505 with firebug.
>
>
> Is that expected?
>
> Thanks,
> Thierry

Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

Johan Brichau-2
In reply to this post by Thelliez
Thierry,

Are you using the WARemoteDebuggingWalkbackHandler to handle exceptions in your app?

I think that's all you need to have the error show up in the object log.

On 12 May 2011, at 18:33, Thierry Thelliez wrote:

> Maybe I set something wrong, but I cannot figure out where to find
> debug info when a Jquey/Ajax call dies.  The usual logs are not
> showing anything.
>
> I am behind Apache/FastCGI (using something similar to what James had
> documented).  The factcgi instance logs, the gemstone/s logs and the
> OS logs are all not showing anything.
>
> The only thing I see is a 505 with firebug.
>
>
> Is that expected?
>
> Thanks,
> Thierry

Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

Thelliez
In reply to this post by James Foster-8
James,

I did not work on this code yesterday, but restarting my dev VM from a
suspended state and having rebooted my laptop this morning, the
expected Seaside Walkback page is back in my browser. Puzzling.

You are right, I forgot to check the object log (not seeing the
Seaside Walkback page, I assumed that the error would be in a log
file).  Now the debug menu shows the errors I was looking for.

Is there any doc I should look at to understand a little bit better
how exceptions are managed?

Thanks,
Thierry
Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

Thelliez
In reply to this post by Johan Brichau-2
Johan,

Could you tell me more about it? And/or is there some write-ups on the topic?

Thanks,
Thierry

>
> Are you using the WARemoteDebuggingWalkbackHandler to handle exceptions in your app?
>
Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

James Foster-8
In reply to this post by Thelliez

On May 13, 2011, at 9:09 AM, Thierry Thelliez wrote:

> James,
>
> ... Is there any doc I should look at to understand a little bit better how exceptions are managed?

The Programming Guide discusses GemStone/S exceptions in general. As to Seaside in general, I'd refer to the various Seaside tutorials and blogs. As to GLASS, I'd refer to Dale's blog.

James

Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

Thelliez
In reply to this post by Thelliez
Some updates on the topic.

1- The absence of feedback on exception is back :-)  On an Ajax
triggered bug the Seaside Walkback html page does not come up anymore.
 The error is in the Object Log. Not a big deal since I can open a
debugger and move on.

2- Johan, I just noticed in the debugger that
WARemoteDebuggingWalkbackErrorHandler is indeed handling my
exceptions. My guess is that the JQuery call (opening a modal dialog)
is in the way of displaying the usual Seaside Walkback html page.



Thanks again,
Thierry
Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

Dale Henrichs
Thierry,

If I'm not mistaken, Ajax responses are handled specially in Seaside
(whether in GemStone or not) and the "standard way of throwing up an
html page when an error occurs" cannot be done with Ajax, because the
browser is not expecting an html response ... so you can't easily get
feedback in the browser itself on an error in response to the the Ajax
call, UNLESS....you write some additional javascript to look for error
conditions and provide your own custom feedback ...

So in GemStone, we toss the the process stack into the ObjectLog for
remote debugging. For remote debugging see:

   http://code.google.com/p/glassdb/wiki/GemToolsDebug

Dale

On 05/13/2011 09:30 AM, Thierry Thelliez wrote:

> Some updates on the topic.
>
> 1- The absence of feedback on exception is back :-)  On an Ajax
> triggered bug the Seaside Walkback html page does not come up anymore.
>   The error is in the Object Log. Not a big deal since I can open a
> debugger and move on.
>
> 2- Johan, I just noticed in the debugger that
> WARemoteDebuggingWalkbackErrorHandler is indeed handling my
> exceptions. My guess is that the JQuery call (opening a modal dialog)
> is in the way of displaying the usual Seaside Walkback html page.
>
>
>
> Thanks again,
> Thierry

Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

Johan Brichau-2
In reply to this post by Thelliez
Thierry,

On 13 May 2011, at 18:30, Thierry Thelliez wrote:

> 1- The absence of feedback on exception is back :-)  On an Ajax
> triggered bug the Seaside Walkback html page does not come up anymore.
> The error is in the Object Log. Not a big deal since I can open a
> debugger and move on.

That is what also happens when working from another Smalltalk.
An error in an ajax callback cannot present the walkback html page because it's not a page refresh.
A debugger is opened server-side when using the right exception handler.

> 2- Johan, I just noticed in the debugger that
> WARemoteDebuggingWalkbackErrorHandler is indeed handling my
> exceptions. My guess is that the JQuery call (opening a modal dialog)
> is in the way of displaying the usual Seaside Walkback html page.

That exception handler will put the continuation on the object log.
You can then open the debugger by selecting it from the list that appears when you click the 'debug' button in gemtools.

best
Johan
Reply | Threaded
Open this post in threaded view
|

Re: How do you debug an Ajax call?

Thelliez
Ok, thanks for the answers. Like you all suggested, it boils down to
javascript error management. Which leads to my next question: is there
a way to do that in Seaside?

I just posted the following to the Seaside group.

Thierry


----------------------------

I encountered two issues regarding exception management:

 ===1===  At one point I had a bug in my code (I know, this never
 happens ;-). The component rendering the dialog did not seem to
 respond to user input.  Inspecting with Firebug, I found that the
 server (GLASS) was returning a 505.  But the debugger (Seaside
 Walkback html page) was not displayed.  Now, I understand that this is
 an issue that has to do with Javascript exception handling.  But how
 do you do that in Seaside?

 In other words, the code below works.  But do you have any code
 example on how to manage exception should my 'myComponent' not behave?

 html div
      id: (html nextId);
      script: (html jQuery new dialog
                html: myComponent;
                title: 'Title';
        height: 180;
        width: 420;
                resizable: false;
        autoOpen: false;
                modal: true).

 html anchor
        url: '#';
        onClick: (( html jQuery id: html lastId) dialog open );
        with: 'Test'


 ===2=== Likewise, I got a 403 when leaving my first calling page
 opened for a while. I mean that attempting to open the above dialog
 does not work anymore after a time that I think is the session
 expiration.  I guess that the link under 'Test' calls
 jquery/javascript, but then the javascript refers to a continuation
 that is expired. (BTW, I am using Seaside 3.0 and GLASS).

 Again, I would like to be able to intercept such exception/error and
 provide something more user friendly.  Right now the dialog opens a
 blank dialog.

 Suggestions?
 Thanks,
Thierry