[Seaside-dev] Re: Making ‘_k’ and ‘_s’ optional: A Seaside Heresy?

[Dale Henrichs]

Julian Fitzell wrote:

>On Sat, Aug 9, 2008 at 12:47 AM, Dale Henrichs
><dale.henrichs at gemstone.com> wrote:
>  
>
>>Julian Fitzell wrote:
>>
>>    
>>
>>>In reference to
>>>
>>>http://gemstonesoup.wordpress.com/2008/08/07/making-_k-and-_s-optional-a-seaside-heresy/
>>>
>>>Dale,
>>>
>>>Heresy schmeresy!
>>>
>>>Amazingly, I have been thinking about this myself over the past few
>>>weeks. I have been refactoring the component hierarchy to give us a
>>>superclass we can actually use that does not support call/answer
>>>(sometimes you don't need it) and does not require a session unless it
>>>needs to persist state. I've also been doing configuration refactoring
>>>and that has had me thinking a lot of dependencies between various
>>>layers of the request handler hierarchy. And I was starting to ponder
>>>whether there wouldn't be some way to have an application use RESTful
>>>urls until a callback was triggered to require a session.
>>>
>>>      
>>>
>>Very interesting this is right in the area I was aiming at. If your RESTful
>>session work in the configuration refactoring packages? If so, I could load
>>it up and start playing with it.
>>    
>>
>
>I haven't really done any coding directly towards this goal but both
>the work in the configcleanup branch and the painter branch might help
>in this regard.
>
>The painter one is possibly the most relevant, the goal being to split
>off the "session" parts of component. WAPainter just provides a
>convenient way to create a reusable, renderable object, and
>WAPresenter provides the basic session hooks (#states, updateRoot: and
>so on) but doesn't actually depend on a session or save state (and
>therefore doesn't support decorations, call/answer, etc).
>
>I want users to be able to implement a completely RESTful application
>(I'm actually thinking more along the lines of an API, but anything
>would be possible) with a handler other than WAApplication (but still
>using reusable component-like objects). But this transitioning case
>may be better handled by a session (or renderer? or context?) that
>notices whether any of the "components" are trying to store state or
>do callbacks. The fuzzy notions in my head haven't quite solidified
>yet.
>  
>
It certainly seems that something relatively straightforward could be 
done here. The solution does seem to cross the session/renderer/context 
boundaries - perhaps some subtle restructuring of repsonsibilities in 
would do the trick?

>What was your reason for implementing all the rendering in your
>example on the dispatcher component, rather than on the Page objects,
>by the way?
>  
>
I had no clearcut idea, but the thought that I could sublcass the 
dispatchter and override a few render methods to modify the structural 
presentation for different components did rattle around in my brain ... 
As I think about I imagine moving the #account iv to a subclass of 
dispatcher and refactor the methods that involve #account logic..then 
using a #call: to invoke the SushiAccountDispatcher when a login occurs 
(with an #answer: on logout) means that the rendering methods for 
various SushiObjects could be easily modified by overriding the render 
method in the dispatcher, rather than complicating the rendering logic 
in the SushiObject itself ... I may do some work on the example to see 
where this kind of approach could lead...

>  
>
>>I think avoiding new session creation would be a good thing, but creating a
>>session and droppping it on the floor is better than hanging onto it when it
>>isn't needed:)
>>    
>>
>
>Agreed. And your tests certainly prove it.
>
>  
>
>>Being able to do a RESTful application using Seaside (that really doesn't
>>save state) goes a long way towards what I was aiming at, but I  imagined
>>that a 95% RESTful Seaside application with 5% taking full advantage of
>>session state would be a powerful weapon and to do that I think you wander
>>into the optional _k, _s territory.
>>    
>>
>
>Seaside is really more than just a continuation-based session engine
>at this point. It would be nice to use it just for the canvas API. I
>played a bit with Rails for the first time the other day: there's so
>much "magic" going on it makes the hairs on my neck stand up. But what
>they do have is an easy way of setting up views and mapping them to
>URLs. The lower levels of Seaside should easily let us provide the
>ability to do something similar.
>
>And things like Pier would be so much nicer if they didn't have the
>session key tacked onto the URL until you actually needed it. For a
>site that is mostly providing a "web page" experience it would be
>awesome to just use meaningful URLs until you log in or add something
>to your cart.
>
>And obviously for many applications, you just want session state from the start.
>
>I think we ought to be able to provide all three options somehow...
>
>Still pondering,
>  
>
Me too...

>Julian
>_______________________________________________
>seaside-dev mailing list
>seaside-dev at lists.squeakfoundation.org
>http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>  
>