seaside-dev January 2012

seaside-dev@lists.squeakfoundation.org

6 participants
5 discussions

cookie based sessions, RESTful urls no _k
by Nick Ager 22 Nov '12

22 Nov '12

Hi, In RESTful applications which also generate continuation key (_k) links a problem can arise if you open multiple tabs all sharing the same session. To illustrate: 1) Enable cookies for http://localhost:8080/examples/counter. 2) Open the counter and increment the value. 3) Open http://localhost:8080/examples/counter in a new tab and decrement the counter. 4) Return to the first counter and increment the value - you will see "-1" rather then "2" ! What I think is happening: If Seaside finds a session but there is no continuation key (_k) then WASession>>#handleFiltered: calls WARenderLoopMain>>#start which in turn creates a new root presenter and calls #initialRequest on the presenter. When the second tab is opened a new WACounter is created and stored in the session's #presenter property. When you return to the first tab, the callback is executed on the first counter, but the second counter is rendered. Ideas for possible fixes: * I thought that #presenter was backtracked so don't understand why the original counter #presenter isn't restored for the callback. If the presenter was backtracked correctly then the counter example should work as anticipated.... however: * in Pier (and potentially other RESTful apps) you don't want to create a new presenter for every RESTful call within an active session. If you don't create a new presenter then #initialRequest currently won't be called, which then won't allow your RESTful app to derive state from the url. If Seaside is modified to call #initialRequest do you need to differentiate between a call on a newly created session and one on an existing session? You could differentiate with a call to a new method on WAPresenter, pass in a flag to #initialRequest, or set a WARequestContext property to indicate a new session had been created. What to do with backtracked state. Do you nil all state before handling the request, restore state from a stored "initial value" snapshot or just use the state of the components from their last handled state? I bought this issue up before [1], but didn't pursue it as I was struggling to understand the issues and ran out of time. Julian responded to my previous email when I was proposing a problematic fix with: I'm not sure it's a good fix in the general case. If you don't have a > continuation key, you shouldn't (by definition) have any existing > (backtracked) state. Relying on the root presenter currently in the > Session is problematic since that value is backtracked for each > request; you'll simply get whichever root happened to be used by > whatever request was last handled by that session. If you don't happen > to be ever changing the root, then it may well be what you want, but > it's not right in the general case. > Incidentally, this also touches on the flaw I was discussing the other > week with our snapshots: because we have no continuation key, we > really ought to nil out any backtracked data before processing the > request (at least that way we have a consistent state while handling > the request). We don't run into the problem with the root presenter > because #start reinitializes it, but for other backtracked state, > you'd just get random stuff in there based on the last-handled > request. > A more appropriate general fix (at least in this case) could be to > take the last-used continuation and apply its state before handling a > request with no _k. However, we don't always know the last-used > (depending on the caching mechanism in place) and I'm not convinced > that is actually always what people want. I still feel pretty > confident that the "right" semantics of an Application/Session request > with no _k is to start a new main/render-loop. Certainly for Pier as it is currently designed I don't think that creating a new render-loop for session requests with the _k is the right thing to do, as it created a new root #presenter. I think ideally Seaside would for existing session with no _k 1) Keep the existing #presenter 2) call #initialRequest with a flag to indicate that a new session hadn't been created. 3) restore the state to an "initial render state" which is snapshotted (?) when the initial render occurs on a new session. Thoughts Nick [1] http://forum.world.st/sessions-continuation-keys-restful-urls-and-component… If each tabs starts with a RESTful url then a new presenter will be created.

3 4

moving document handlers to session
by Philippe Marschall 23 Jan '12

23 Jan '12

Hi I hope an can attend the Pharo Sprint at Feb 18./19. and repurpose it to hack on Seaside. One thing I'd like to do is moving the document handlers from registry to session. Pros: * simple * adding a document handler no longer potentially expires a session * expiring a session expires all it's document handlers * session tracking code becomes much simpler Cons: * #urlXXX methods on WARenderContext only work with sessions (a fallback could be added in theory) * #urlXXX methods on WARenderContext need to become class extensions of the Seaside-Session package * not really clean framework-framework Endlösung Cheers Philippe

2 3

Grease-Pharo-Core-lr.45
by Philippe Marschall 22 Jan '12

22 Jan '12

Hi I couldn't find a discussion, issue or unit test relating to Grease-Pharo-Core-lr.45. Should this be merged into 3.1? Cheers Philippe

2 4

Unsubscribe
by Dan Winkler 22 Jan '12

22 Jan '12

On Sunday, January 22, 2012, Julian Fitzell <jfitzell(a)gmail.com> wrote: > Thinking totally off the top of my head, but what if it was implemented as a filter? A few helper methods on WARequestHandler (or subclasses) could add an instance if it's missing and then add the document and return a URL... > Julian > > On Sun, Jan 22, 2012 at 1:57 PM, Philippe Marschall < philippe.marschall(a)gmail.com> wrote: >> >> Hi >> >> I hope an can attend the Pharo Sprint at Feb 18./19. and repurpose it >> to hack on Seaside. One thing I'd like to do is moving the document >> handlers from registry to session. >> >> Pros: >> * simple >> * adding a document handler no longer potentially expires a session >> * expiring a session expires all it's document handlers >> * session tracking code becomes much simpler >> >> Cons: >> * #urlXXX methods on WARenderContext only work with sessions (a >> fallback could be added in theory) >> * #urlXXX methods on WARenderContext need to become class extensions >> of the Seaside-Session package >> * not really clean framework-framework Endlösung >> >> Cheers >> Philippe >> _______________________________________________ >> seaside-dev mailing list >> seaside-dev(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > >

2 1

unsubscribe
by Dan Winkler 22 Jan '12

22 Jan '12

On Sun, Jan 22, 2012 at 9:35 AM, Philippe Marschall < philippe.marschall(a)gmail.com> wrote: > 2012/1/22 Lukas Renggli <renggli(a)gmail.com>: > > Yes, this should be merged. There was definitely a discussion about > > this in the mailing-list. As far as I recall this broke existing tests > > in Pharo 1.3. > > That's interesting because the tests of Seaside 3.1 in Pharo 1.3 seem > to run on Jenkins [1] even though it doesn't have the fix.The only > test that doesn't run is WAMutexTest >> #testSelfTerminate. But if you > download the image then it runs as well. > > [1] http://jenkins.lukas-renggli.ch/job/Seaside%203.1/ > > Cheers > Philippe > _______________________________________________ > seaside-dev mailing list > seaside-dev(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev January 2012