Smalltalk › Frameworks & Tools › Seaside › Seaside General

Keep-alive timer for Seaside app

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

tfleig

Keep-alive timer for Seaside app

Hi,

I want to keep my Seaside app's session from expiring as long as the
user's browser page is open, even if the user does not interact with
the page.

I came up with the following method and it seems to work when rendered
in the page.

My questions are:
Is there better way to do this?
Is there an easier way to get the cacheTimeout value?
Do I really need two JSScript instances to create the interval
timer? I couldn't find a better solution.

renderKeepAlive: html

| script cacheTimeout |
cacheTimeout := self session application cache expiryPolicy
configuration at: #cacheTimeout.
script := JSScript new
add: (JSScript new
add: (html jQuery ajax callback: [
Transcript cr; show: 'keepalive']));
interval: (cacheTimeout - 60) seconds asDuration.
html document addLoadScript: script.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli

Re: Keep-alive timer for Seaside app

> My questions are:
>    Is there better way to do this?
>    Is there an easier way to get the cacheTimeout value?

Looks good.

>    Do I really need two JSScript instances to create the interval
> timer? I couldn't find a better solution.

You should be able to send #interval: to the JQAjax instance with a
cascade (same receiver as #callback:). No need for JSScript.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

EstebanLM

Re: Keep-alive timer for Seaside app

I do this:

html script: (html jQuery ajax
callback: [ "Do nothing" ];
interval: self interval)

you really don't need a response to client side :)

Cheers,
Esteban

El 06/01/2011, a las 3:46a.m., Lukas Renggli escribió:

>> My questions are:
>> Is there better way to do this?
>> Is there an easier way to get the cacheTimeout value?
>
> Looks good.
>
>> Do I really need two JSScript instances to create the interval
>> timer? I couldn't find a better solution.
>
> You should be able to send #interval: to the JQAjax instance with a
> cascade (same receiver as #callback:). No need for JSScript.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

tfleig

Re: Keep-alive timer for Seaside app

Maybe this is more complex than I thought:

When I use my original script:

| script cacheTimeout |
cacheTimeout := self session application cache expiryPolicy
configuration at: #cacheTimeout.
script := JSScript new
add: (JSScript new
add: (html jQuery ajax callback: [ ]));
interval: (cacheTimeout - 60) seconds asDuration.
html document addLoadScript: script.

everything works fine. And by that I mean scripts elsewhere in the app
are executed normally, for example this one:

html checkbox
value: (self items at: k);
onChange: ( 'updateItemStatus($(this));');
onChange: (html jQuery ajax callback: [
Transcript cr; show: 'callback'])

However, if I change my load script to this:

| script cacheTimeout |
cacheTimeout := self session application cache expiryPolicy
configuration at: #cacheTimeout.
html document addLoadScript: (
html script: (
html jQuery ajax
callback: [];
interval: (cacheTimeout - 60) seconds))

The checkbox onChange script and callback never happen.

I don't understand what is going on here. Somehow the load script is
interfering with ajax execution elsewhere on the page. Inspection of
the source code has revealed nothing obvious to me.

I'm sure there is some piece of Seaside that I don't understand here.
Can anyone help me understand what's going on?

Cheers,
TF

On Thu, Jan 6, 2011 at 3:13 AM, Esteban Lorenzano <[hidden email]> wrote:

> I do this:
>
> html script: (html jQuery ajax
> callback: [ "Do nothing" ];
> interval: self interval)
>
> you really don't need a response to client side :)
>
> Cheers,
> Esteban
>
> El 06/01/2011, a las 3:46a.m., Lukas Renggli escribió:
>
>>> My questions are:
>>> Is there better way to do this?
>>> Is there an easier way to get the cacheTimeout value?
>>
>> Looks good.
>>
>>> Do I really need two JSScript instances to create the interval
>>> timer? I couldn't find a better solution.
>>
>> You should be able to send #interval: to the JQAjax instance with a
>> cascade (same receiver as #callback:). No need for JSScript.
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

tfleig

Re: Keep-alive timer for Seaside app

A follow-up:

If I do not use addLoadScript: and just render the script to the page,
then the problem disappears.

Is it the case that jQuery ajax scripts in the load scripts can
inhibit ajax execution for the whole app?

Why does my original script not cause the problem when it is used as a
load script?

I compared the generated Javascript and the same code is generated
regardless of whether the script is loaded using addLoadScript: or
not.

TF

On Thu, Jan 6, 2011 at 8:53 AM, Tony Fleig <[hidden email]> wrote:

> Maybe this is more complex than I thought:
>
> When I use my original script:
>
> | script cacheTimeout |
> cacheTimeout := self session application cache expiryPolicy
> configuration at: #cacheTimeout.
> script := JSScript new
> add: (JSScript new
> add: (html jQuery ajax callback: [ ]));
> interval: (cacheTimeout - 60) seconds asDuration.
> html document addLoadScript: script.
>
> everything works fine. And by that I mean scripts elsewhere in the app
> are executed normally, for example this one:
>
> html checkbox
> value: (self items at: k);
> onChange: ( 'updateItemStatus($(this));');
> onChange: (html jQuery ajax callback: [
> Transcript cr; show: 'callback'])
>
> However, if I change my load script to this:
>
> | script cacheTimeout |
> cacheTimeout := self session application cache expiryPolicy
> configuration at: #cacheTimeout.
> html document addLoadScript: (
> html script: (
> html jQuery ajax
> callback: [];
> interval: (cacheTimeout - 60) seconds))
>
> The checkbox onChange script and callback never happen.
>
> I don't understand what is going on here. Somehow the load script is
> interfering with ajax execution elsewhere on the page. Inspection of
> the source code has revealed nothing obvious to me.
>
> I'm sure there is some piece of Seaside that I don't understand here.
> Can anyone help me understand what's going on?
>
> Cheers,
> TF
>
>
>
> On Thu, Jan 6, 2011 at 3:13 AM, Esteban Lorenzano <[hidden email]> wrote:
>> I do this:
>>
>> html script: (html jQuery ajax
>> callback: [ "Do nothing" ];
>> interval: self interval)
>>
>> you really don't need a response to client side :)
>>
>> Cheers,
>> Esteban
>>
>> El 06/01/2011, a las 3:46a.m., Lukas Renggli escribió:
>>
>>>> My questions are:
>>>> Is there better way to do this?
>>>> Is there an easier way to get the cacheTimeout value?
>>>
>>> Looks good.
>>>
>>>> Do I really need two JSScript instances to create the interval
>>>> timer? I couldn't find a better solution.
>>>
>>> You should be able to send #interval: to the JQAjax instance with a
>>> cascade (same receiver as #callback:). No need for JSScript.
>>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>> _______________________________________________
>>> seaside mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: Keep-alive timer for Seaside app

In reply to this post by tfleig

On 06 Jan 2011, at 17:53, Tony Fleig wrote:

> | script cacheTimeout |
> cacheTimeout := self session application cache expiryPolicy
> configuration at: #cacheTimeout.
> html document addLoadScript: (
> html script: (
> html jQuery ajax
> callback: [];
> interval: (cacheTimeout - 60) seconds))
>
> The checkbox onChange script and callback never happen.
>
> I don't understand what is going on here. Somehow the load script is
> interfering with ajax execution elsewhere on the page. Inspection of
> the source code has revealed nothing obvious to me.

The argument of addLoadScript should be a String or a JSScript.
In the code above, it's the return value of the statement "html script: ... ", which is the WACanvas instance (in the html variable) itself.

Inspection of the source code should have revealed that. Are you not using something like Firebug (or any other development tools in Chrome or Safari) at the client side?

A crash of javascript on your page will prevent it from executing the other javascripts (onChange handlers) on your page.

Try the following:

| script cacheTimeout |
cacheTimeout := self session application cache expiryPolicy
configuration at: #cacheTimeout.
html document addLoadScript: (
html jQuery ajax
callback: [];
interval: (cacheTimeout - 60) seconds)_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

tfleig

Re: Keep-alive timer for Seaside app

Ah. I understand. Thank you for the explanation.

What confused me was that the interval callback was working in every case.

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.

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?

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.

I have to say that I like the way solutions to problems in Smalltalk
often seem to result is less code rather than more.

Regards,
TF

On Thu, Jan 6, 2011 at 10:36 AM, Johan Brichau <[hidden email]> wrote:

>
> On 06 Jan 2011, at 17:53, Tony Fleig wrote:
>
>> | script cacheTimeout |
>> cacheTimeout := self session application cache expiryPolicy
>> configuration at: #cacheTimeout.
>> html document addLoadScript: (
>> html script: (
>> html jQuery ajax
>> callback: [];
>> interval: (cacheTimeout - 60) seconds))
>>
>> The checkbox onChange script and callback never happen.
>>
>> I don't understand what is going on here. Somehow the load script is
>> interfering with ajax execution elsewhere on the page. Inspection of
>> the source code has revealed nothing obvious to me.
>
> The argument of addLoadScript should be a String or a JSScript.
> In the code above, it's the return value of the statement "html script: ... ", which is the WACanvas instance (in the html variable) itself.
>
> Inspection of the source code should have revealed that. Are you not using something like Firebug (or any other development tools in Chrome or Safari) at the client side?
>
> A crash of javascript on your page will prevent it from executing the other javascripts (onChange handlers) on your page.
>
> Try the following:
>
> | script cacheTimeout |
> cacheTimeout := self session application cache expiryPolicy
> configuration at: #cacheTimeout.
> html document addLoadScript: (
> html jQuery ajax
> callback: [];
> interval: (cacheTimeout - 60) seconds)_______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: Keep-alive timer for Seaside app

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

sebastianconcept@gmail.co

Re: Keep-alive timer for Seaside app

>> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Intrader Intrader

Re: Keep-alive timer for Seaside app

I have a hunch that it is a restriction of how many scripts maybe in the loading
process. A script may not load until a previous script has finished executing so
therefore the interval is interfering with the loading and execution of the
second script.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside