[Seaside] Seaside sessions and ajax

sig siguctua at gmail.com
Fri May 18 18:17:17 UTC 2007


Thanks for reply!

On 18/05/07, Lukas Renggli <renggli at gmail.com> wrote:
> > I found that it handles differently, not like a regular page navigation.
> > For instance - continuation is not changing.
>
> Yes, AJAX handlers are executed (rendered) exactly the same way as a
> callback would. This means it always evaluates the continuation of the
> full page refresh, leading to several very subtle problems.
>
> > And i have a problem with sessions: when session expires, by default
> > we redirect page to show login page. But with ajax its just returns an
> > empty result, rendering updated page parts empty. How i can handle
> > session expiration with ajax correctly?
>
> It does not return an empty result, but an error response. As you can
> see in WAApplication>>#handleExpiredRequest: and its super
> implementation WARegistry>>#handleExpiredRequest:. This allows you to
> catch this case in the error handler #onFailure: of SUAjax (for one
> particular AJAX handler) or SUResponders (for all AJAX handlers).
>
so, i can add #onFailure: handler for my updater ?
can you please point to small code snippet using this. Im asking
because its pretty hard to express some meaningfull javascript
statements with current SUScript interface.
For example, for generating a simple javascript
if (...) { statements}  statements
i have a following horror code in smalltalk:

script := (renderer element id: elemId; hide;
					replace: '<div style="display:none" id="', elemId
,'">Loading...</div>'; return: false)
					condition: (renderer element id: elemId; visible);
					after:
						(renderer updater id: elemId;
							callback: [ :html |  (self wikiViewerFor: helpObject)
renderViewerOn: html id: elemId ]),
						(renderer effect id: elemId; appear).

I think this must be changed to more convenient form for generating a
scripts by server.

And if you know how, please tell me how i can set a default OnFailure
handler in ajax, because putting onFailure: everywhere is too
excessive.


> > Also, i would like to make continuations updating for ajax, so any
> > user action regardless ajaxed or not with have new continuation id.
> > How this can be done?
>
> This is a thing on the to-do list of Seaside 2.8. Another related
> problem is that the backtracking doesn't work (mildly expressed) with
> AJAX. If you or anybody else has an idea about a possible solution to
> these problem I would be glad to hear. So far I couldn't come up with
> a nice solution myself ...
>
I don't think that ajax must support backtracking. It must be used for
atomic operations. Any other needs can be handled in general way,
bacause it adds too much complexity on top of what we already have,
gaining a minor bonuses.

I just need the seaside generate new continuation for Ajax requests.
Backtracking a javascript actions seem pointless to me.

About possible solution: suppose we already having a seaside
generating new continuation for each Ajax request.
Then on any answer we need to get new continuation id. And use this
new id for browser navigation. It means that all anchor/forms must use
this new id.
This can be done by changing the Href generation in seaside. Instead
of putting static _s,_k values, we need to put in all our Href-s a
call to javascript function, which composes requests based on current
_s, _k values received from last Ajax update request (or use initial
values if there was none of them).

Or, we can go in other way:
All what i need to have is, when user navigates via link, to preserve
the WAStateHolder values modified by Ajax requests invoked by some
user actions on page. Currently, seaside ignoring these changes and
reloads them from point when page was first loaded.

> Cheers,
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>


More information about the seaside mailing list