Re: [picocontainer-dev] [Paul?] DPC.initForConfig()

--- Paul Hammant <[email protected]> wrote:

> I see your point Konstantin.
> 
> If we were to imagine ConfigAdapter in the style of
> InstanceAdapter  
> for exclusive use by addConfig(..) what what would
> it do that is  
> different ?
> 
> All the work is done in
> BasicComponentParameter.getTargetAdapter(..)  
> - it would be there that we change functionality, if
> we were to  
> change it.
> 
> Before we change anything though, what would happen
> in the following  
> scenario ..
> 
>     public class NeedsString {
>         public NeedsString(String foo) { .. }
>     }
>     dpc.addComponent(NeedsString.class)
>     dpc.addComponent(String.class,"is it me you're
> looking for?");
>     dpc.addConfig("foo","is it me you're looking
> for?");
>     dpc.getComponent(NeedsString.class)
>     // ?

I think in this case it should be clear ambiguity


But here are my 2c on parameters ( CL )  or properties

injection. 

I would propose special containers for CL parameters /
system properties / whatever properties. Of course, 
it is not wise to just register all strings found on
CL
into container and submit them to injection. 

So, APC could be renamed CLPC ( Command Line PC ) 
and be backed by commons-cli ( which can also validate
params etc. ). Only params described in CL-descriptors
gets registered into container. (I do not like
problems like strts 2 got recently - OGNL code through
parameters was executed)

The same for [system]properties - some kind of
configuration is necessary in such container. 

Adapters in thos containers shall be kind of different
from vanilla ones, because they shall handle
conversion from string values to appropriate types. 

Now to parameter resolution - at the moment all the
work is done in
BasicComponentParameter.getTargetAdapter(..) - which
is kind of complicated( with advent of parameter names

even more).  Why not take inversion of control a step
further?

Since matching adapter to parameter becomes
complicated ( we have to take not only explicit key,
or implicit type but also  parameter nameand in case
of "config" we do not care for type as it shall be
converted from string ) -  it shall be adapter that
decides whether it is fit for parameter [and return
value] - this way parameter just asks container "give
me the list of adapters who like to satisfy me"  - and
then checks whether something came back.


Adapters become a method to "accept" provided
parameter:

 - "ConfigAdapter" should accept (or better said
"match"?) explicit request on his config entry name
or property name
- "Vanilla" adapter either explicit name or by type
etc. 

Another adapter question:
What about base adapter class which utilizes object
reference? There is common logic in cached / thread
local / JNDI / JMX etc. - just store entry into
reference or remove from it. 


WDYT? 

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


       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

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

    http://xircles.codehaus.org/manage_email