[Seaside-dev] WAMutualExclusionFilter

[Julian Fitzell]

Why didn't this email go to the Seaside dev list as well? sigh...

On Mon, Nov 23, 2009 at 5:19 PM, Julian Fitzell <jfitzell at gmail.com> wrote:
> What I'm suggesting would put the transaction handler a few contexts
> later. "self requestHandler" would return a particular request handler
> that could be set/configured by the server adaptor itself. Your server
> adaptor could configure that handler by adding several filters to do
> logging/transactions/retry in whatever order it liked.
>
> Once its filters had finished processing, the special request handler
> would dispatch to the root handler specified by the user (usually a
> Dispatcher).
>
> I'd like to avoid another layer of handlers if possible... would it be
> enough to catch WAResponseNotification, do something, then send #next?
> I keep meaning to provide an ensure-like method that does that
> automatically so that filters can specify behaviour that happens
> either when a block finishes *or* when a response is sent back.
>
> Julian
>
> On Mon, Nov 23, 2009 at 2:21 PM, Dale Henrichs
> <dale.henrichs at gemstone.com> wrote:
>> Julian,
>>
>> Yes that sounds like it is in the right area ... it would be a bonus to have the transaction handling inserted underneath the error handling for the session (and a bonus to insert special exception handlers above the error handlers for dealing with retry). For logging, at times it is useful to be able to get your hands on the WARequest/REsponse .. I like to drop them into the object log.
>>
>> Some of the tracing that I do must be done in conjunction with the transaction boundaries, so being able to swap in and out different transaction handlers is necessary too.
>>
>> Looking at the stack, the transaction handler/logger probably needs to be wrapped around WAServerAdaptor>>handleRequest: ... since we're interested in the request/response boundary, but I assume that can be achieved by making the WAResponseNotification handler a separate handler layer in and of itself..
>>
>> Dale
>>
>> ----- "Julian Fitzell" <jfitzell at gmail.com> wrote:
>>
>> | On Sat, Nov 21, 2009 at 9:37 AM, Dale Henrichs
>> | <dale.henrichs at gemstone.com> wrote:
>> | >
>> | > ----- "Philippe Marschall" <philippe.marschall at gmail.com> wrote:
>> | >
>> | > | <rant>
>> | > | We have that over and over again. Error handlers, key generators,
>> | > | codecs, semaphores, .... Every time we do a different hack,
>> | looking
>> | > | at
>> | > | subclasses, looking at some class var somewhere, liking against a
>> | > | platform provided class, looking the class up in WAPlatform, ....
>> | I'm
>> | > | fucking sick of it, I want dependency injection!
>> | > | </rant>
>> | >
>> | > Is there a reason for not using dependency injection? We do have
>> | quite a few moving/configurable parts and it sure would be convenient
>> | to have a single spot to manage the choices ....
>> | >
>> | > Hmmm, perhaps the injector, should be configured prior to the
>> | loading of the code ... the developer decides how they want there
>> | Seaside instance configured (making error
>> | handling/codec/decorator/adaptor choices), then a system that matches
>> | those specs is loaded ... over time as the composition of the system
>> | (and even the implementation changes), the same choices could be
>> | preserved ...
>> | >
>> | > Okay, I'll add a method to GRPlatform:)
>> | >
>> | > Seriously, though. For the short term I will create a
>> | gemstone-specific branch on the session package with the hope that a
>> | better approach becomes available.
>> | >
>> | > I _am_ also looking at a putting decorator-style handlers in the
>> | Adaptor stack for transactions, logging and maybe even
>> | conversion...maybe I'll play with dependency injection there?
>> |
>> | We discussed creating a special RequestHandler to represent the
>> | server
>> | adaptor as the first handler in the handler stack. I think this would
>> | simplify a few things, for example allowing that adaptor to alter the
>> | generated URLs based on information obtained from the server adaptor
>> | itself. Obviously it could provide default error handling (or be
>> | wrapped in a request filter), though I wondered if that would be
>> | quite
>> | high enough?
>> |
>> | I started implementing this at one point but then was not sure there
>> | were enough immediate benefits to avoid it looking like
>> | over-engineering. Would something like this address help with what
>> | you
>> | want to do?
>> |
>> | Julian
>>
>