Peter Donald wrote:
>
> At 03:16 3/4/01 +0200, Leo Simons wrote:
> >perhaps org.apache.avalon for the framework
> >and org.apache.avalon-util (.aut) for utilities
> >and org.apache.cornerstone for the components?
>
> Well cornerstone is components hosted by the kernel so IMHO it is not
> really appropriate for free standing components.
>
> In an absolute ideal situation I would like to see
>
> org.apache.aut.* (utility)
> org.apache.avalon/framework.* (framework)
> org.apache.agora/???.* (components)
>
> however I don't have the cycles for that at the moment - especially not if
> we plan to go beta by the time c2 goes beta. So hence the compromise ;)
> Though if someone else wanted it badly enough ...
I think that the org.apache.avalon and org.apache.framework approach would
be the best compromise. So to your original proposal, I will append my +1.
> >> Anyway thats the basic outline of something we can do. One thing I do have
> >> a query about is whether we want to keep the interface "Component" around.
> >> Currently "Component" is what is returned from ComponentSelector and
> >> ComponentManager which means that any components stored in those objects
> >> must implement COmponent. This can be a PITA when you want to store JDK
> >> type objects in the CM - I have run afoul of it a number of times and have
> >> a number of classes who only exist to implement Component. Hence I would
> >> like to make CM and ComponentSelector return Object instead and completely
> >> remove the Component interface.
> >
> >I've seen the problem too. But the disadvantage is the removal of the
> >conceptual
> >"Component". A way to avoid that would be to have
> >
> >Component ComponentManager.generateComponentFrom(java.lang.Object object);
> >
> >which wraps the thing. Might be some complicated rtti stuff there, though.
>
> yep I am not really sure how to handle this ;)
Personally, until we come up with a way to approach this properly and maintain
the concept of a Component, then we should just keep things as they are ATM.
Can I ask you what you were trying to accomplish with trying to use the
ComponentManager for something other than a Component? It could be a case of
using the wrong tool for the task. I believe that Cocoon 2 has the purest
implementation of the Component Management Framework. I also remember that
when we _used_ to have the NamedComponent and NamedComponentManager we were
trying to blend two different patterns and contracts into one class. That's
why we came up with the ComponentSelector approach.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
