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

[Julian Fitzell]

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.

Now my thinking was more along the lines of having no session at all,
rather than creating a new default session for each request. But I
haven't really thought through as far as an implementation yet and
doing it that way might well require too much manual effort on the
part of the developer, so creating a new session each time may be
unavoidable.

It seems like you may be going further and advocating dropping the _k
even once a persistent session has been created?

Also, we need to remember that _k isn't only needed for callbacks, but
also for backtracked UI state like whether a tree is expanded and so
on. We'd be losing out on that possibility as well. Again, I was sort
of picturing the developer creating a RESTful browsing interface
without any state, but of course you could presumably just detect if
any of the components returns anything in #states and start tracking
_s and _k at that point.

I haven't looked at your code yet but may try to do so today.  In
general, though, I definitely think the idea is interesting and the
goal worth pursuing if we can do it cleanly and without it feeling
hacked in.

Cheers,

Julian