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

Tue Aug 19 21:02:15 UTC 2008

I've implemented something similar for Cmsbox a while ago, which works  
very well. Our situation probably is a bit special since on the one  
hand we have almost pure "window shopping" and on the other hand a  
rich GUI for editing web pages. Since the distinction between the two  
parts is clear it did not require many changes to our implementation  
nor to Seaside.

"Window shopping" links are URLs without _k and _s keys, although the  
session key is stored in a cookie (e.g., an URL may look like http://cmsbox.com/en/system) 
. If the client does not support cookies, there exists no fallback for  
_s into the URL, that is, on each request a new session is created.  
This happens mostly for search bots.

There are a few situations in which we use callbacks in the window  
shopping mode, for instance for the search, for lightboxes, forms, or  
for the login link. Those URLs always include the _k key, and include  
the _s key if _s is not passed by the cookie. As a consequence, when  
clicking on such a link, the previous session will be used without  
creating a new one.

The motivation for this is to have truly nice URLs (which is an  
important point for customers) and to provide better indexable sites  
for search bots (Google suggests not using any arguments in URLs).

Cheers,
Adrian
___________________
http://www.adrian-lienhard.ch/

On Aug 13, 2008, at 18:15 , Dale Henrichs wrote:

> 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
>>
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev