> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > > I think the key is to have the second lookup (to find the > component B > > that is contained in C) standardized via a interface. > > Personally I think the exact opposite ;) > > I HATE the ComponentSelector interface and think it is a huge > mistake to use > it. If the ComponentSelector is simply access to a category of avalon > components then I can't see why you can't depend on/lookup a > component > directly.
Keep in mind the purpose of the Selector/Manager relationship. The selector is much better or more elegant when we have something like Cocoon. The components available for Generation, Transformation, or Serialization are many. Plus it is hard to determine what should be the actual mapping to the specified component. For example: Generator.ROLE + "/file" Generator.ROLE + "/stream" Generator.ROLE + "/foo" Truth be told, the File and Stream options can both be used to get the same results.... So how do we choose the suffix safely? The Selector is better here. > ie Consider case where you look up selector with > SocketManager.ROLE then look > up SocketFactory component using "ssl" hint. Why could you > not instead lookup > the ssl factory directly via SocketFactory.ROLE + "/ssl". In this case, it might be just better this way. You have two options: SSL and no SSL. > Much easier to do dependency checking, much easier for > component implementer > and gives the assembler much more choice in assembling the system. And the more complex ways are having the container take care of it all for you. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
