[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