cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] ComponentManager/Selector Rearchitecture
Date Tue, 20 Mar 2001 13:38:40 GMT
Peter Donald wrote:
> 
> Maybe what would be to refactor the *Info into something useful to both
> Phoenix/Cocoon.

The big thing is that it would have to be part of Avalon--there is no sense
in including a server with a servlet.

> The only issue then is that Cocoon woul dhave to include the extra
> attribute "version" for each service. I don't think this is too much overhead.

This is not a problem.

> >On Monday 19 March 2001 20:37, Berin Loritsch wrote:
> >> I will try to see where it would fit in the Avalon Framework.  It would be
> >> perfect for replacing the DefaultComponentManager implementation in
> >> Avalon--but the Handler and Factory implementations may need a
> >> subpackage.
> >
> >The C2 class mentioned by Berin (ComponentFactory) implements ObjectFactory,
> >not (phoenix) Factory. This class doesn't really deal with pooling, though.
> >
> >Is there some degree of redundancy between Factory and ObjectFactory?

I am not sure.  I altered ObjectFactory to be an ObjectFactory (it creates
Objects, not Poolables).  That way it can be used in Factory contexts and
in Pooling contexts.  That is how I have one class that handles the
commissioning and decommissioning of Components.  It really reduces the
amount of redundant code, and makes the system more stable.

> Yep - the difference mainly was that ObjectFactory deals with only one type
> while Factory deals with multitude of types. As Avalon progresses I suspect
> we will see a homogenisation of these cases.
> 
> >At this point we want to be sure we're making the right decision as to what
> >to base our blocks upon.
> 
> You mean blocks as in Phoenix Blocks or just components in general.

The framework I created is for Components.  It works quite well in that scope.
I would be sad to see it deal exclusively with Blocks.

> >At first sight it appeared to us that just
> >generalizing C2's component management classes and proposing moving them to
> >the Avalon top-level package would be the right thing to do (tm), but your
> >comment appears to suggest that Camelot would be the right place to move
> these
> >components. What do you think?
> 
> Not really sure - what do you think of the above approach. If that was
> adopted we could make a new package that dealt with management and
> delegation of roles/services. Dependency trees between components (I assume
> that doesn't exist in Cocoon???) could also be dealt with by build a DAG etc.

Here is my input: I refactered Cocoon so that Cocoon can have a good foundation
for ComponentManagement and Selection.  If we move that framework into Avalon,
it benefits a wider population.  If we move it to Camelot or Pheonix, then we
again narrow our focus and the classes are of no use to Cocoon--why move them?
They _need_ to be in Avalon, and then specializations can be made in Camelot
or Pheonix.  I propose moving the Component framework to Avalon, with a really
simple Role tool, and then we can create specializations that would really
benefit Camelot or Pheonix.

Anything else would not only be a loss of focus, but wouldn't benefit the
largest group of people.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message