seaside-dev May 2012

seaside-dev@lists.squeakfoundation.org

5 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

Moving Seaside-REST from Addons to "Core" in 3.1
by Philippe Marschall 01 Jul '12

01 Jul '12

Hi I want to move Seaside-REST from Addons to the "Core" repository in Seaside 3.1: The reasons are the following: - the code base has stabilized and has been jürgenized by Lukas - we have documentation in the book [1] - several people use it I'm aware this will probably cause problems for some people but I don't think leaving it in addons or having it in both places are good alternatives either. Is this absolutely terrible or somebody (Dale?)? Personally I think of the addons repository as something similar to Apache Incubator. A place where we can experiment. If things turn out well we can graduate them to the core repository. [1] http://book.seaside.st/book/advanced/restful Cheers Philippe

4 6

[ANN] CodeMirror / WABrowser with Smalltalk Syntax highlighting
by Torsten Bergmann 24 May '12

24 May '12

Hi there, I wrote a simple seaside wrapper for the CodeMirror JavaScript Editor, the code lives in http://ss3.gemstone.com/ss/Seaside-CodeMirror It was actually very easy to wrap due to the new WAFileMetadataLibrary facility. Since this editor includes also a "Smalltalk mode" you can also use the project in combination with the attached patch changeset for WABrowser to style your web served Seaside code browser/editor. (Screenshot attached) Look at http://codemirror.net/mode/smalltalk/index.html to try the mode online. Have fun! Bye Torsten -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

Seaside31 comments
by Dale Henrichs 17 May '12

17 May '12

Philippe, These are my unfiltered comments on the configurations. I want you to take the comments with a grain of salt, because my comments are intended to inform not explicitly criticize. I'll make remarks in detail, but I don't think it is worth it for you to make detailed responses. I don't intend on spending a lot of time explaining/defending my comments, unless something doesn't make sense to you or you feel strongly ... those are the areas that are worth discussing in my opinon. There's lots of wiggle room in defining specs so there aren't too many black and white issues ... if the configuration validates cleanly it should be good to go. I didn't finish looking at all of the specs, but I think I've hit enough of the highlights to get the ball rolling... Dale ------------General---------------------------------- 1. Eventually you will have one package per configuration, instead of all the configurations in one package. ------------ConfigurationOfSeaside31---------------------------------- 1. #seaside304DoIts is probably not needed in 31. Include only if you have proven that you need it. 2. you've included a bunch of GemStone packages ... are those know to work or just included from 3.0? 3. The #project method has extra cruft that is no longer needed ... replace with MetacelloBaseConfiguration>>project. 4. Strip the class side development support category... I think there is better toolbox support for the operations ... keep the #validate method. 5. it's worth looking at Versionner to see if it performs the require development operations. Let Juan know if it Versionner needs work... 6. Do you plan on continued support of Swazoo in 3.1? 7. The 'default' group loads 'Core' and 'Tests' are you sure that you want to continue with that? Starting from a blank slate, I would do things differently for Seaside3.1: - 'Base' renamed to 'Core' with tests following suit - 'default' includes 'Core' only - 'Production' to include the "tools recommended for production" - Move 'Seaside-HTML5' 'Seaside-Tools-Web' 'Seaside-Swazoo' 'Seaside-Adaptors-Swazoo' 'Seaside-Tools-OmniBrowser' 'Seaside-FileSystem' to a separate configuration (tests too) 8. Actually, I'd create ConfigurationOfSeasideCore31 ... it would include all of the packages in the 'Base' package. Most of the packages that depend upon Seaside would reference ConfigurationOfSeasideCore31. 'default' group for this configuration should just be the non-test packages. 9. The ConfigurationOfSeaside31 would then include the packages that are in the current ConfigurationOfSeaside31, but not in ConfigurationOfSeasideCore31...this would probably make it possible to do away with the *commonBaseline: method (created because of 256 literal limit). Group definitions as follows: - 'default' includes the "kitchen sink", Tests' and all packages since we've separated out the Core to a separate configuration - 'Core' includes the ConfigurationOfSeasideCore31 - 'Production' includes ConfigurationOfSeasideCore31 and "tools recommended for production"...no 'Tests' - 'Development' includes ConfigurationOfSeasideCore31 and development packages (excluding 'Seaside-HTML5','Seaside-Tools-Web', etc.), includes 'Tests' 10. ConfigurationOfSeaside31 would also include references to the other Seaside31 configurations: ConfigurationOfComet31, ConfigurationOfSeasideRest31. etc. Including them here would make it convenient for someone to create a nice load expression that includes everything they want for their project: (ConfigurationOfSeaside31 project version: #stable) load: #('Production', 'Seaside-Zinc', 'Rest', 'JQuery', 'Seaside-HTML5') 11. You are still including Kom as the default adaptor ... did you want to switch to KomLite or Zinc as the default? 12. 'Comet-Core' 'Comet-Examples' 'Comet-Tests-Core' still included in the baseline310: spec. ------------ConfigurationOfGrease---------------------------------- 1. Grease 1.1.0 is defined in the copy of Grease in the Seaside3.1 repository. There needs to be only one _master copy_ of the Grease configuration and that's in the Seaside3.0 repository. 2. ConfigurationOfGrease and the packages will be shared between Seaside3.0 and Seaside3.1. 3. It's not Grease if it has to be forked for Seaside3.1. 4. ConfigurationOfGrease does not validate correctly: #baseline110: is specifying version '1.0.0-baseline' not '1.1.0-baseline' 5. there are additional validation errors after fixing number 4. 6. strip the class-side development support category (keep the #validate method:). ------------ConfigurationOfRss31---------------------------------- 1. I now understand what you meant by "look for it in ConfigurationOfSeaside31". Metacello works slightly differently than you think. Here's the recast baseline spec: baseline310: spec <version: '3.1.0-baseline'> spec for: #'common' do: [ spec blessing: #'baseline'. spec description: ''. spec repository: 'http://www.squeaksource.com/Seaside31'. spec project: 'Seaside-Core' with: [ spec className: 'ConfigurationOfSeaside31'; versionString: #'bleedingEdge'; loads: #('Seaside-Canvas'); repository: 'http://www.squeaksource.com/MetacelloRepository' ]; project: 'Seaside-Canvas' copyFrom: 'Seaside-Core' with: [ spec loads: #('Seaside-Canvas') ]; project: 'Seaside-Tests-Core' copyFrom: 'Seaside-Core' with: [ spec loads: #('Seaside-Tests-Core') ]; project: 'Seaside-Tools-Core' copyFrom: 'Seaside-Core' with: [ spec loads: #('Seaside-Tools-Core') ]. spec package: 'RSS-Core' with: [ spec requires: #('Seaside-Core' 'Seaside-Canvas') ]; package: 'RSS-Tests-Core' with: [ spec requires: #('RSS-Core' 'Seaside-Tests-Core') ]; package: 'RSS-Examples' with: [ spec requires: #('RSS-Core' 'Seaside-Tools-Core') ]. spec group: 'Base' with: #('RSS-Core'); group: 'Base Tests' with: #('RSS-Tests-Core'); group: 'Base Examples' with: #('RSS-Examples') ] And the the version310: would looke like: version310: spec <version: '3.1.0' imports: #('3.1.0-baseline')> spec for: #'common' do: [ spec blessing: #'release'. spec description: 'release 3.1.0 see http://code.google.com/p/seaside/wiki/Seaside310Changelog'. spec project: 'Seaside-Core' with: '3.1.0'; project: 'Seaside-Canvas' with: '3.1.0'; project: 'Seaside-Tests-Core' with: '3.1.0'; project: 'Seaside-Tools-Core' with: '3.1.0'. spec package: 'RSS-Core' with: 'RSS-Core-pmm.68'; package: 'RSS-Examples' with: 'RSS-Examples-lr.26'; package: 'RSS-Tests-Core' with: 'RSS-Tests-Core-lr.30' ] a similar technique can be applied to each of the other configurations that reference ConfigurationOfSeaside31. 2. with the above modifications here's what will happen when you load ConfigurationOfRss31: (ConfigurationOfRss31 project version: '3.1.0') record: 'Base' a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 3.1.0 [ConfigurationOfRss31] load : ConfigurationOfSeaside31 linear load : 3.1.0 [ConfigurationOfRss31] load : ConfigurationOfSeaside31 linear load : 3.1.0 [ConfigurationOfRss31] linear load : 3.1.0 [ConfigurationOfSeaside31] load : ConfigurationOfGrease linear load : 3.1.0 [ConfigurationOfSeaside31] linear load : 1.1.0 [ConfigurationOfGrease] load : Grease-Core-pmm.74 load : Grease-Pharo-Core-pmm.52 load : Grease-Pharo13-Core load : Seaside-Core-pmm.773 load : Seaside-Pharo-Core-pmm.21 load : Seaside-Canvas-pmm.122 load : Seaside-Pharo-Canvas-pmm.4 linear load : 3.1.0 [ConfigurationOfSeaside31] linear load : 1.1.0 [ConfigurationOfGrease] load : Grease-Pharo13-Core load : Grease-Tests-Core-pmm.84 load : RSS-Core-pmm.68) If one loads Rss31 as currently defined, you will not have a "functional seaside" loaded as not even the 'Base' packages are defined. This means that a developer will have to explicitly load the 'Core'/'Base' group (depending upon which definition we end up with) of Seaside31 to get a "functional seaside". UNLESS Seaside-Core and Seaside-Canvas CAN function as a standalone unit, in which case the spec is "perfect"... 3. You will want to define a 'default' group for each of the projects. For ConfigurationOfRss31, the 'default' group include 'RSS-Core'

2 3

Seaside 3.1 ready
by Philippe Marschall 14 May '12

14 May '12

Hi I feel Seaside 3.1 ready for release [1] - apart from the usual refactorings and cleanups we managed to fix 2 of the 3 major regressions in 3.0 [2] - session continuations are now WARequestHandlers - we have a new WAPluggableActionContinuation - the session tracking code has been refactored, it's simpler and supports new features - document handlers are no longer stored as sessions - JSON support has been updated - HTML5 support has been updated What's missing right now are Metacello configurations. I started working on them but would welcome help. I updated ConfigurationOfGrease to version 1.1, that was easy but the GemStone versions of course still point to 1.0.7. I did not rename it to ConfigurationOfGrease11. Dale, should I rename this? I started a Seaside configuration named ConfigurationOfSeaside31. Dale, is this OK our should I name it ConfigurationOfSeaside30? This is a bit more problematic, because I run into the 256 literal limit in #version310:. I did not add the new packages Seaside-JSON-Core, JQuery-JSON and Seaside-REST to any group. Dale, tell we how you want this done and I'll do it. [1] http://code.google.com/p/seaside/wiki/Seaside310Changelog [2] http://code.google.com/p/seaside/wiki/BigIssues Cheers Philippe

3 11

Seaside and Magritte
by Philippe Marschall 14 May '12

14 May '12

Hi I had this totally ridiculous idea. The Seaside configuration "framework" basically rebuilds Magritte-Core and Magritte-Seaside. What about if we replace these parts with Magritte? We'll have to pay attention to dependency loops like Magritte-Seaside depending on Seaside and Seaside depending on Magritte-Seaside especially for things like #componentClass:. I'm well aware of the down-sides: - More dependencies - Harder to port, you'll need to port Magritte first which requires pragmas - Magritte version of Seaside shared with applications using Magritte I'm not seriously proposing or pushing this, I just wanted to provide some food for thought. I was probably under too much Eclipse 4 / EMF influence lately. Cheers Philippe

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev May 2012