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.
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
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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
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 estebanlm@gmail.com 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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
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 tony.fleig@gmail.com 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 estebanlm@gmail.com 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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
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)
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 johan@inceptive.be 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 seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
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
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@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
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@lists.squeakfoundation.org
-
Esteban Lorenzano -
Fritz Schenk -
Johan Brichau -
Lukas Renggli -
Sebastian Sastre -
Tony Fleig