avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Resolver package--Please post your thoughts
Date Wed, 13 Feb 2002 10:04:08 GMT
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:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message