PRContext, PRContextFilter, cookies enabled, component creation and Restful urls
renggli at gmail.com
Fri Jan 27 08:57:52 MET 2012
> What's happening? In the Pier 2 case:
> * PRPierFrame>>#initialRequest is called for every Restful url. There is no
> distinction between a call when a new session has been created and a call
> with an existing session.
Is this the correct behavior? Looks like a bug in Seaside, it should
only call #initialRequest: when the session object is created. Julian
might know more ...
> * In PRPierFrame>>#initialRequest a new PRContextFilter is added to the
> session: "self session addFilter: (PRContextFilter on: self)"
I see, there are countless filters added. Now it would be easy to
detect if a filter is already present, but then the root cause seems
to be somewhere else ...
> * In WASession>>#handleFiltered: aRequestContext, if there is no
> continuation key, #start is called on the session, which creates a new root
> component - in this case a new PRPierFrame.
That's a Seaside bug, no?
> * So every time we browse to a Restful url a new PRPierFrame is created
> which holds the PRContext. This context is then "held" by the
PRPierFrame should be preserved, because it is stageful. With and
> * A new PRPierFrame is only created when a new session is created. This
> should then function as Pier 1. However if the root presenter is exchanged
> in one open tab e.g. with a #call or #show on the root, then other open tabs
> will not operate as intended.
The root presenter is backtracked, so this should be fine.
> The implementation would I think require a
> custom session with a custom #handleFiltered: or alternatively a modified
> WASession which allows configurable behaviour when there's no continuation
I think the current behavior of WASession is broken. Does the plain
Seaside counter without Pier work at all if cookies are enabled?
> * If however we want to allow for multiple components so that state isn't
> maintained between two identical Restful - that is both counters start at 0.
> Then we could move PRContext into the session, and remove the
All components should preserve their state across their session. Also
I would try to avoid depending on a specific WASession, that was a big
problem in Pier 1 because you could not easily use it in your own
application (for example as a help or documentation system).
More information about the smallwiki