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

[Julian Fitzell]

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.

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 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,

Julian