PRContext, PRContextFilter, cookies enabled, component creation and Restful urls
nick.ager at gmail.com
Mon Jan 23 20:06:48 MET 2012
Today I checked-in a fix which reverts a change I made to try to stop
multiple PRContextFilter s being added to the session filter chain.
Unfortunately the fix caused unintended side-effects, which I believe
contributed to the problems Sergio mentioned. Hopefully the reversion
should fix some or all of these problems.
However there's still an issue with the interaction of PRContext,
PRContextFilter, cookies, component creation and Restful urls. To
illustrate the issue execute the following:
| app rootPage |
rootPage := (PRPage named: 'rootPage') contents: '+counter+'; yourself.
rootPage localEnvironment: ((PRComponent named: 'contents')
componentClass: PRContentsWidget; yourself).
rootPage addChild: ((PRComponent named: 'counter') componentClass:
app := PRPierFrame registerAsApplication: 'contexttest' kernel: (PRKernel
named: 'contexttest' root: rootPage).
then browse to http://localhost:8080/contexttest You should see a counter
instance. Increment the value of the counter once. Then in a new window/tab
of the same browser, browse to same url (http://localhost:8080/contexttest)
and decrement the value of the counter once. Now return to the original
value and increment again - the counter displays the value "-1" rather than
If I try the same test in Pier 1, (note in Pier 1 you'll have to manually
enable cookies through the /config), when I first browse to the second tab,
the counter already displays "1".
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.
* In PRPierFrame>>#initialRequest a new PRContextFilter is added to the
session: "self session addFilter: (PRContextFilter on: self)"
* 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.
* 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
What does this mean in our counter example:
In the first tab a new session is created, a new PRPierFrame, a new
PRContextFilter and a new WACounter instance are created. The link to
increment the counter contains a continuation key so #initialRequest isn't
called and callback is fired incrementing the counter which in turn
In the second tab the session already exists, however without a
continuation key a new PRPierFrame, a new PRContextFilter and a new
WACounter instance are created. Decrementing the counter decrements it on
the new WACounter instance.
Now returning to the first tab we again try to increment the counter. The
callback on the first component created is called and the counter is
incremented. However in the rendering phase, the second component created
in the second tab is displayed, with it's counter unincremented and set to
What are the problems:
* There is no distinction between #initialRequest called with a newly
created session and #initialRequest called from a session recovered via a
cookie. Neither is there an obvious way of detecting for which case
has been called.
* Within WASession>>#handleFiltered: if no continuation key exists a new
root component is created.
* A new PRContextFilter is added for each Restful call.
Two possible solutions:
* 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 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
* 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
I hope this makes sense I've I understood the situation correctly. Any
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the smallwiki