[Seaside-dev] Some Feature Requests

[Julian Fitzell]

On Tue, Oct 28, 2008 at 11:23 AM, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
> Julian Fitzell wrote:
>> On Tue, Oct 28, 2008 at 10:22 AM, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>>> 1. Please could you at least add a properties dictionary to WASession.
>>> This is extremely useful, and allows multiple features to be added to
>>> Seaside as plugins/addons/helpers without subclassing WASession.
>>>
>>
>> Would you expect such a dictionary to be backtracked or not? I think
>> this would be the trickiest part of this.
> I have never needed it to be backtracked.

Really? I can think of stuff you would want to put on session
(authorization state, for example) that would want to be backtracked.
Making it backtracked isn't tricky; what's seems sticky to me is
knowing which properties should be and which shouldn't. Don't take
this necessarily as opposition to having properties, by the way, I'm
just thinking out loud.

> When someone subclasses WASession to add instVars to support a database
> (some other session like behaviour) I have never seen anyone attempt to
> backtrack what they put in there.
>
> I also use these properties to hold a flag to indicate whether the
> ToolBar on and off, if a user is authorized to view the toolbar, the
> property gets set on the session, and the ToolBar helper (which is added
> as a decoration to the root component) displays accordingly.
>
> These are helpers that provide additional sessions, sessions on
> databases etc.
>>  The helpers you are thinking
>> of
> These helpers exist and are used, but I had to resort to hackery because
> WASession as not extendible in any way shape or form.

Well it was always intended that you would extend it by subclassing.
:) I realize that can cause problems without multiple inheritance, and
it doesn't preclude having a properties dictionary. But in my
experience, every project I've worked on has ended up having behaviour
added to the Session just as much as properties, so I would have
needed to subclass it anyway. I guess you're adding this behaviour
onto a standalone class that keys its data of the session?

> There is code in http://www.squeaksource.com/Jetsam in package
> Seaside28Jetsam. Everyone who wants to add a database to seaside ends up
> having to subclass WASession, as does comet, ShoreComponents.
>
> ...
>

Obviously I'll have to take a look at your code at some point to see
what you mean.

>>  might also work better as RequestFilters, which are new in 2.9
> Is there some docs on these somewhere?

Not yet, unfortunately. They basically follow the same pattern as
Decorations but are attached to request handlers (likely either an
Application or Session in most cases). They are given a chance to
process the request before the request handler they are wrapping. This
came out of the observation that most things people were installing as
"root component decorations" really wanted to wrap the whole session.
Most of the sample decorations Seaside provides ended up making more
sense reimplemented as RequestFilters.

>>> removeItem: item id: id on: script
>>>
>>>    script effect id: id; dropOut.
>>>
>>>    "remove item from the database,
>>>        a) without slowing the UI interaction
>>>        b) within the scope of this session/db session etc"
>>>
>>>    self session postServeBlocks add:  [ self removeItem: item ] .
>>>
>>
>> I can see how this would be useful. If you want it to run in the same
>> process, the process monitor would have to deal with it, which is
>> unfortunately pretty hairy code. :) We currently guarantee that only
>> one process is executing within a session at a time.
>
>> Maintaining this
>> guarantee while allowing the incoming process to resume will be
>>
> I just use the standard process monitor critical: block.

I'm not sure what you mean, but obviously I'll have to look at the code.

>> somewhat messier, but certainly not impossible. But does that offer a
>> significant benefit over simply using a streaming HTTP server so that
>> the response is being streamed as it is generated?
>>
>>
> I have no idea what this sentence above means.

Well, the reason you want behaviour "after the reponse finishes" is
presumably because you want the user to see the page content without
waiting for the action to complete. If you are streaming the HTTP
response, though, they will begin seeing content as you are outputing
it anyway. So, if you are using a streaming HTTP server, is there a
benefit to having the internal session process perform actions after
it has returned a response? Don't you get the same behaviour by just
doing the action after you have done rendering (but before you
actually return from the handler)? The content has already gone to the
user at that point.