Berin Loritsch wrote: > I have tried to address all the shortcommings of the > ComponentManager/ComponentSelector > approach in the Resolver package. (located in Avalon Framework > src/proposals directory). > If you find that this package does *not* support your needs, or > appears clumsy/difficult > to use, please air your grievances now. > > Please either take the approach of fine-tuning the interfaces or of > providing an alternative. > It also helps when you state the reasons why you beleive your > alternative is better :)
One thing's that scares me is the use of arrays for obtaining results. While this allows for one-call retrieval of many objects, this can easily lead to some nasty bugs related to ordering/numbering of Query keys, even more considering that query items are added in a non-indexed way using "Query.addKey()", and objects retrieved in an indexed way using "Token.references()[i]". So the question is : is multiple lookups in one call really needed ? > Since everyone is keen on removing the necessity of marker interfaces > sooner than later, > I want a smooth migration path. That means that we need a replacement > for Component > resolution (without the Component interface). > > It also means that we should do the following: > > * Promote ComponentHandler interface and implementations to Framework > * Provide standard mechanism for registering a Component with a handler > - ComponentInfo? (like BlockInfo) Something that's missing in component management is some formal description of components : blockinfo provides block dependencies, but we could also have a formal description of the configuration of the component (I don't want to say XMLSchema because of it's heavy weight). This would allow building some tools that rely on this information, such as conf file checkers (are all components correctly configured, and their dependencies satisfied ?) or GUIs for the graphical assembly of a system. > - Manifest entries? > - Other? > * Finalize Resolver framework, or whatever the replacement ends up being > > If this seems like a winning migration path, and we really like this > approach, we can make > it a part of Framework 4.2 or something like that. It is important > that we have working > implementations though. BTW, I know quite well CM/CS for having used it a lot in Cocoon and my projects, but not much Phoenix. It seems to me (and the current discussions enforce this feeling) there's a lot of redundancy both in concepts and code between Service/Block and Component interface/implementation. Moreover, looking at the "what-is-a-block" page, many of the given examples are what we have as components in Cocoon. From what I can, see, a block can provide several services (but AFAICS, most of them provide only one), whereas a component implements only one role. Could you enlighten me on this or point me to relevant resources (other than the web site) ? Thanks, Sylvain -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
