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

[cdrick]

2008/8/8 Julian Fitzell <jfitzell at gmail.com>:
> 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.

This sounds to me like Seaside 3.0 :)

my 2 cents...

Cédrick


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