[Seaside-dev] Some Feature Requests

[Keith Hodges]

Julian Fitzell wrote:
> On Tue, Oct 28, 2008 at 10:22 AM, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
>   
>> I haven't looked at 2.9 yet but I would like to request a couple of
>> essentials.
>>
>> 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.

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.

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.

Since I am using three databases simultaneously, with shore components,
the code in Seaside28Jetsam probably covers most use cases. There is
also Magma seasideHelper which defines 5/6 variations on the theme of
helpers for Magma, these hook in to just about everything that WASession
has to offer.

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

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

As well as the example above I use the postProcessBlocks so that after
the user hits the application, he gets his front page, then it kicks off
the process of getting him a non-shared magmaSession (this session needs
to be attached to his WASession). If that same user happens to respond
too quicky, then he will simply have to wait. But the chances are 5
seconds will pass before he has finished typing in his login name and
password etc.

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