[Seaside] Keep-alive timer for Seaside app

[Sebastian Sastre]

>> I'm a little disappointed that there wasn't a more useful indication
>> of what the error actually was and where it occurred, like a walkback
>> in the Smalltalk environment or something.

Seaside does some pretty damn good magic to give you the illusion that the web isn't there but there is a hard limit. 

That hard limit is the VM where javascript is running.

Only that VM will be able to provide you of that walkback and firebug and the WebKit stuff does kind of a decent job for not being smalltalk (check the stop on all errors thing from its console).

What we do in production is to capture the exception on the onError handler of ajax calls and post that to the server side. We get the info of which component complained (failed to initialize at the DOM or failed to re-initialize after an updater or whatever DOM). It works using a redirect to a callback that will capture the error kindly so the user sees a decent error page.

Al least it's a start that we have for knowing that: 
1. something happens 
2. when 
3. how frequently and
4. where (in which component's code)
5. our users know that we know that some sh*t happened there




On Jan 6, 2011, at 7:02 PM, Johan Brichau wrote:

> 
> On 06 Jan 2011, at 20:52, Tony Fleig wrote:
> 
>> What confused me was that the interval callback was working in every case.
> 
> That's indeed something I would not expect either, but I would have to see the generated code to understand anyway.
> 
>> And I didn't realize that a failure in a load script would prevent
>> execution of Javascript that (from my viewpoint) is attached to events
>> and unrelated to the load script. Inspection of the generated code
>> makes it clear that Seaside is packaging it all up together, using
>> bind() to assign the event handlers, hence its susceptibility to
>> errors early in the Javascript code. Something to remember.
> 
> It's not the case for all inline event handlers, but it's the case for some of them. 
> 
>> Safari's dev tools did show a "parse error" and provided the line on
>> which it occurred. Unfortunately, the line was the entire 5000+
>> characters of Seaside-generated Javascript and it was not clear to me
>> where in that mess the problem was happening. Still, I suppose I
>> should have tracked that down since it would have ultimately led to
>> the solution. I don't suppose there is an option I don't know about to
>> have Seaside generate formatted Javascript? How do other people deal
>> with this situation?
> 
> Unfortunately, that's a problem I'm also struggling with a lot. The key is not to generate large javascripts but use external javascript files and generate only what you really need to. That makes debugging your javascript errors easier.
> In case something happens in an onload script, I'm often justing putting a halt in the method where the script is rendered and I manually inspect the generated script in a Smalltalk inspector.
> 
>> I'm a little disappointed that there wasn't a more useful indication
>> of what the error actually was and where it occurred, like a walkback
>> in the Smalltalk environment or something.
> 
> That's not feasible because the error happens in the javascript code at the client side. When that happens, there is no walkback to go to (not technically, nor conceptually: the javascript code is generated).
> But I understand: when you are used to debugging in Smalltalk, debugging javascript is probably the entire other end of the spectrum.
> 
> cheers
> Johan_______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside