Re: [picocontainer-dev] Config , Properties and API struggle

I can't help jump in, because I have the similar requirements/problems while
using/extending Pico1.x, though I'm not very unfamiliar the new
implementation in pico2


Konstantin Priblouda wrote:
> 
> Ugliest part of it ( IMHO of course ) is
> MutablePicoContainer.addConfig(String, Object) - as it
> just a wrapper for adding instance adapter and does
> not introduces any new semantics. 
> 
Agree, I don't think it's a good thing to introduce too much new concerns
into the Container implementation. 


Konstantin Priblouda wrote:
> 
> There is also some ugliness in "by param
> name"-fallback in dependency resolution ( which by
> chance breaks nano-groovy )- why do we need this at
> all? It usefullnes is quite limited (and I would say
> potentially dangerous and confusing for users - 
> try to explain them why it is needed to use certain
> formal  parameter names in constructors ) 
> 
Agree, I prefer auto-wire by type is the default behavior, and if user do
really want to wire by name, just add a hint in the parameter and injector
can read from that.


Konstantin Priblouda wrote:
> 
> Anyway I think that reference to [external] 
> configuration item shall be always explicit. 
> And place them into special parent containers 
> (like attributed) is generally good idea, but needs
> some improvement. 
> 
Yes, but I think it would be much simple and natural if we could just store
the parameters in some external store and the container can regard those
parameters as normal component beans.
My solution is to support OGNL style component key. For exmaple, we register
the configurations parameter map into container with key "config", then we
can reference those values in other component's dependency with key
"config.foo", "config.bar". 

Let's think one step further, we can introduce an interface, for example
IExternalStore, and provide a implementation ServletStoreAdapter. Then we
can reference the request parameter in some container managed action like
below

public class FooAction{
  @Parameter("request.param.id")
  public Long id;
  @Parameter("request.param.foo")
  public String foo;
}



> Current implementation by Paul supports only 
> integers, booleans and strings - which is not very
> generic approach. It would be really cool to support 
> more (at least all primitives from java.lang , maybe
> java.io).  Another prolem is, that it registers
> components with certain type ASAP - but it is 
> depending component which decides what type his config
> entry is (say, the same property could be needed as
> string or number. or integer / float) 
> 
We may need a expendable value convert mechanism like PropertyEditor in
Spring.

Regards,

Shawn.
-- 
View this message in context: http://www.nabble.com/Config-%2C-Properties-and-API-struggle-tf4401169.html#a12566952
Sent from the NanoContainer - PicoContainer - Dev mailing list archive at Nabble.com.


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

    http://xircles.codehaus.org/manage_email