seaside-dev November 2012

seaside-dev@lists.squeakfoundation.org

4 participants
6 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

which version of Seaside-Pharo-Tools-OmniBrowser for 3.1?
by Paul DeBruicker 14 Nov '12

14 Nov '12

The current ConfigurationOfSeaside30 asks for Seaside-Pharo-Tools-OmniBrowser.pharoOB-NickAger.7 which is only found in the Seaside30 repo. The latest in the Seaside31 repo is Seaside-Pharo-Tools-OmniBrowser-lr.7

4 6

Grease - set author initials?
by Paul DeBruicker 14 Nov '12

14 Nov '12

Using Grease can you set the author initials of an image on Squeak and Pharo? If not is that something that should/could be added ?

3 5

Seaside 3.0.7 & 3.1 build testing on Travis
by Paul DeBruicker 14 Nov '12

14 Nov '12

Hi- For Seaside 3.1 I've set travisci.org to run the following jobs: - ST=PharoCore-1.1 LOAD="'Development Tests'" - ST=PharoCore-1.1 LOAD="'Tests' 'Development Tests' 'JQueryUI Tests' 'Kom Tests'" - ST=PharoCore-1.2 LOAD="'Tests' 'Development Tests' 'JQueryUI Tests' 'Kom Tests'" - ST=PharoCore-1.3 LOAD="'Tests' 'Development Tests' 'JQueryUI Tests' 'Kom Tests' 'Zinc'" - ST=Pharo-1.4 LOAD="'Tests' 'Development Tests' 'JQueryUI Tests' 'Zinc'" - ST=Pharo-2.0 LOAD="'Tests' 'Development Tests' 'JQueryUI Tests' 'Zinc' " - ST=Squeak-4.3 LOAD="'Tests' 'Development Tests' 'JQueryUI Tests' 'WebClient'" - ST=Squeak-4.4 LOAD="'Tests' 'Development Tests' 'JQueryUI Tests' 'WebClient'". For Seaside 3.0.7 I've set it to run these jobs: - ST=PharoCore-1.1 LOAD="'Core' 'Tests'" - ST=PharoCore-1.2 LOAD="'Core' 'Tests'" - ST=PharoCore-1.3 LOAD="'Core' 'Tests'" - ST=Pharo-1.4 LOAD="'Core' 'Tests'" - ST=Pharo-2.0 LOAD="'Core' 'Tests'" - ST=Squeak-4.3 LOAD="'Core' 'Tests'" - ST=Squeak-4.4 LOAD="'Core' 'Tests'" You can see the results here: https://travis-ci.org/pdebruic/ConfigurationOfSeaside30 On that page there is a branch summary tab. The 'master' branch is for 3.1. On each branch's summary page there is a link for each job. At the bottom of the job's page there is a list of what went wrong, if the tests ran or a stack trace if the packages could not finish loading. The summary is Pharo 2.0 needs a newer VM than the current Smalltalk setup for travis provides. For seaside 3.1: 'Tests' all pass on all platforms 'Development Tests' have at least one failure or error on all platforms and does not load into Pharo1.1 'JQueryUI Tests' fails on Pharo 1.4 because JSConversionTest>>#testNumber fails

2 1

WAComponentTest>>#testChildComponentShouldNotBeSelf never ends in Seaside 3.1
by Paul DeBruicker 11 Nov '12

11 Nov '12

Also the WAChildComponentShouldNotBeSelfError does not exist in the default load. When I create that error class the test still does not complete..

1 1

Seaside 3.1 release?
by Paul DeBruicker 11 Nov '12

11 Nov '12

In May there was a discussion about getting the 3.1 configuration ready for release. Did that get completed or is there a list of tasks somewhere that I could work on to move it forward? Has 3.1 been released or is there a date set for releasing 3.1? I ask because it looks like there hasn't been anything 3.1 related uploaded to the squeaksource repo since September 3rd. Thanks Paul

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev November 2012