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

Wed Aug 20 03:37:29 UTC 2008

Hi Adrian,

Can you provide any more implementation detail? Where did you put the
check for whether to include the _k? How did you handle creating the
URLs for links? (did you just manually build the URLs as strings in
the generating component?)

What (if any) did you feel were the limitations of your approach?

Julian

On Wed, Aug 20, 2008 at 5:02 AM, Adrian Lienhard <adi at netstyle.ch> wrote:
> 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
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>