[Seaside-dev] WAMutualExclusionFilter

[Julian Fitzell]

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