[picocontainer-dev] useNames() and parameter resolution / proposal

Konstantin Priblouda <kpriblouda-/[email protected]>
Newsgroups gmane.comp.java.picocontainer.devel
Message-ID <[email protected]>
Hi all, 

After hunting down failing test in nano-groovy
I ran (yet again) into conceptual questions in
parameter
resolution. (
testCanActOnConfigAndParameterNameToResolveAmbiguity(org.nanocontainer.script.groovy.GroovyNodeBuilderTestCase)
)

It looks to me that current 3-way component binding 
( explicit by key, implicit by type, implicit by 
parameter name ) needs some clarification /
streamlining. 
(Current test failure comes clearly from lack of
setting useNames() by o.n.s.ComponentElementHelper
called from component node. ) 

I find that current resolution of parameteres grows
out of control. 

IIRC resolution by parameter name was introduced for
injecting configuration values (correct me if I'm
wrong) Do we need it at all? 

What about some internal inversion of control? 
At the moment, it is component parameter which hunts
down suitable adapters in container - thus it has to
know all the modalities ( by key, by type by param
name ) of various component adapters, and also be
configurable. 

I think shifting decision to adapter, whether it
qualifies for certain puprose would make things
simplier. (for example "config"/system properties 
adapter would respond to both string / numeric values 
if it can convert data, vanilla one only if 
key / type matches etc. )

WDYT? 

regards,

----[ Konstantin Pribluda http://www.pribluda.de ]----------------
JTec quality components: http://www.pribluda.de/projects/


       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.