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

--- Shawn <[email protected]> wrote:

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

Solution with new kind of parameter could be easily
backported to 1.x - so it is not a big concern. 


> 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.

it's not wiring by name - wiring by name/key was
always there.  it is additional fallback wiring  by
declared parameter name. 

> 
> 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". 

Are you coming over from s2/ww2 ? ;) 
I do not think this will be a good idea - too
complicated and possible name clashes.  Our parameer
keys are not bound to be strings - it kan be
everything. 

Parent contaienrs will do also ( and provide defaults
/ overriding capability ) 

> 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

in integration with struts, struts is in charge of it.

actins are instantiated and injected by pico, and then
comes interceptor and fills in parameters

( there is a much more in it - value conversion, 
sanitizing etc - not out concern somehow ) 



> We may need a expendable value convert mechanism
> like PropertyEditor in
> Spring.

there a re a lot of implementations  around - java
beans property editors,  xwork converters, xstream 
etc. 

the question is, whether we like to to depend on
something in core, nano or develop our own
(xml scripting stuff could profit from it)

I feel that core shall be pure vanilla java without
any foreigh dependency - so this converter stuff could
be integrated with nano or gems. 


regards,

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


       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

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

    http://xircles.codehaus.org/manage_email