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]
