Hi,
Even if i'm newbie to avalon, i'd like to comment this out with my *external*
vision.
Quoting Leo Simons <[EMAIL PROTECTED]>:
> The only way to cleanly get out of this is to use rigorous
> interface-implementation seperation combined with loose coupling between
> implementation and 'framework' by using an adaptor/wrapping setup. The
> layers IMV:
>
> NON-FRAMEWORK UTILITY CODE (1)
> --------------------------------------
> CLIENT FRAMEWORK INTERFACES (2)
> --------------------------------------
> CONTAINER FRAMEWORK INTERFACES (3)
> --------------------------------------
> CLIENT FRAMEWORK UTILITY CODE (4)
> --------------------------------------
> CLIENT FRAMEWORK IMPLEMENTATION (5)
> --------------------------------------
> CONTAINER FRAMEWORK UTILITY CODE (6)
> --------------------------------------
> CONTAINER FRAMEWORK IMPLEMENTATION (7)
> --------------------------------------
> OTHER CODE (8)
I completely aggree to that. I would enhance this view like this:
-------------------------------------------------------------------------------
NON-FRAMEWORK INTERFACES (1)
-------------------------------------------------------------------------------
NON-FRAMEWORK IMPL (2) | CLIENT FRAMEWORK INT (3)
-------------------------------------------------------------------------------
CLIENT FRAMEWORK IMPL (4)
-------------------------------------------------------------------------------
COMPONENTS REPOSITORY INT (5) | CONTAINER CLIENT FRAMEWORK INT (7)
-------------------------------------------------------------------------------
COMPONENTS REPOSITORY IMPL (6) | CONTAINER CLIENT FRAMEWORK IMPL (8)
-------------------------------------------------------------------------------
(1) commons...
(2) commons...
(3) avalon framework + Instrumentable
(4) avalon framework impl + Instrumentable impl
(5) excaliburn, cornerstone, your components and mine interfaces
(6) excaliburn, cornerstone, your components and mine implementations
(7) container abstraction services interfaces
(8) phoenix, fortress, merlin...
Note that (8) can be based on (6) whereas any component of (6) MUST not be based
on (8) but on (7).
Application/Component developpement takes place above (3) for simple components
and on (7) for main application components (that need a container).
This is why (7) itself could be split in two:
- a service for components to delegate lifecycle handling
Something like ContainerUtil but as an interface and that has only three
methods *createAnObject*, *startupAnObject* and *shutdown* an object. For me the
selector interface is pretty good for this.
- some services for components that requires a container with some behaviour
modify extension points
Something like a subset of Fortress. But the simpler is the better.
Maybe that (7) relies on (4) is erroneous. However, i did not have enough place
with 80 columns and such big names.
> Not saying I am against "doing it cleanly", just that it is something to
>
> tackle _after_ we get fortress out. You know, reduce the headache.
Nevertheless i think the framework should be cut (int/impl) before the 4.1.4
release. And framework abstraction of the container should be specified and
added before this release too.
> cheers,
>
> - Leo
Cheers, Didier.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
