PRContext, PRContextFilter, cookies enabled, component creation and Restful urls

[Lukas Renggli]

> 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
> PRContextFilter.

PRPierFrame should be preserved, because it is stageful. With and
without cookies.

> * 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
> key.

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
> PRContextFilter.

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).

Lukas

-- 
Lukas Renggli
www.lukas-renggli.ch