[Seaside-dev] WAMutualExclusionFilter

Dale Henrichs dale.henrichs at gemstone.com
Sat Nov 21 17:37:20 UTC 2009


----- "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? 

Dale


More information about the seaside-dev mailing list