seaside-dev April 2012

seaside-dev@lists.squeakfoundation.org

5 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

Grease on Pharo 2.0
by Dale Henrichs 26 Apr '12

26 Apr '12

This morning we got a request to get Grease ported to Pharo2.0 ... The issue is that the class BlockContext is not present in Pharo2.0. So we have a packaging decision to make and we have several options: 1. rename Grease-Pharo-Core to Grease-Pharo20-Core for Pharo2.0 2. fork Grease-Pharo-Core for Pharo2.0 creating Grease-Pharo-Core.pharo20 3. move the BlockContext methods from Grease-Pharo_Core to Grease-Pharo1x-Core ... no need for a GreasePharo2x-Core package yet. 4. other alternatives? For now I will proceed with option 3 just to find out if there are any other 2.0 related issues, but I won't commit any public packages until you guys let me know what your decision is ... Dale

2 5

HTML 5 multiple attribute
by Philippe Marschall 22 Apr '12

22 Apr '12

Hi With the HTML 5 multiple attribute [1] <input> elements now can have multiple values. Right now only the first one is passed to the callback block because WACallback >> #evaluateWithFieldValues: only uses the first one. What do people think would be the best way to solve this? I don't really want to create new tag classes for multiple valued tags. What I can think of is a "multiple" instance variable in WAFormInputTag and WAValueCallback. Not very nice, but would work. [1] http://dev.w3.org/html5/spec/single-page.html#the-multiple-attribute Cheers Philippe

2 2

Re: [Seaside] Problems with WANoDuplicateUuidsTest and Magritte image
by Lukas Renggli 16 Apr '12

16 Apr '12

Good catch! Normally this test is run directly after Seaside is loaded [1], where it passes. It seems to loop on 'Magritte-Seaside' though. Looks like the ancestry there is somehow broken :-( +philippe.marschall I wonder why this test duplicates the (complicated) logic to traverse package ancestries instead of using #topologicalAncestors or #withBreadthFirstAncestry? These two methods would work, even on the broken 'Magritte-Seaside'. Lukas [1]: http://jenkins.lukas-renggli.ch/view/Pipeline/job/Seaside%203.0/lastComplet… On 16 April 2012 01:41, Martin Sandiford <ms(a)mcdev.com.au> wrote: > Hi Folks, > > If I download the latest Magritte 2 image from here: > http://jenkins.lukas-renggli.ch/view/Pipeline/job/Magritte%202/ and > run the WANoDuplicateUuidsTest, it runs forever. > > Well at least for an hour on my Mac before I gave up :) > > This doesn't happen with the Seaside 3.0.7 one-click or image, so it > seems like something is happening while loading Magritte. > > Is this a known issue? > > Cheers, > Martin > > P.S. Thanks for the awesome framework that Seaside is! > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Lukas Renggli www.lukas-renggli.ch

2 3

ConfigurationOfSeaside30 version 3.0.7 refers to Zinc version 1.2
by Paul DeBruicker 05 Apr '12

05 Apr '12

In the ConfigurationOFZincHTTPComponents I made yesterday the latest/stable version is 1.5. So the Seaside configuration doesn't load a new version of Zinc and instead relies on whats provided in the Pharo images. Changing the version of Zinc to 1.5 (or better yet #stable) in the Seaside config and reloading Seaside loads the new version of Zinc. Also- the Seaside builds for Pharo 1.3 on the Pharo CI server are using a ConfigurationOfSeaside30 thats 4 versions old.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev April 2012