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

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

> 
> > after some recapitulation I think that introducing
> new
> > kind of parameter would be the smallest evil
> > ( this would hunt CAs by key only - external
> config
> > entity has to be explicit - and try to convert
> > string from it into object - this can be made
> > configurable )
> > Such parameter will be able to work with
> attributed PC
> > (which could be simplified to just register
> > string/string). on top of APC we could build
> > different varieties - filled with string array,
> > properties or off commons-cli or whatever else.
> > ( and addConfig() becomes obsolete )
> 
> 
> I fear that would not be elegant in use dude.  I
> almost never use the  
> current parameter design now.
> 
> What I will commit later for Groovy will be ..
> 
>                  nano = builder.container {
>                     config(key:'foo', value:'one')
>                     config(key:'bar', value:'two')
>                    
> component(class:NeedsString.class, properties: 
> [ USE_NAMES ])
>                  }
> 
> Following that I may do ..
> 
>                  nano = builder.container {
>                     config(key:'foo', value:'one')
>                     config(key:'bar', value:'two')
>                     properties( USE_NAMES ) {
>                        
> component(class:NeedsString.class)
>                     }
>                  }
> 
> (NeedsString has a ctor with a single String
> param-name of 'foo')
> 
> How would yours look in Groovy ?

well, we have to take care not only of groovy. 
I would prefer that config entries live in parent
container (rigged up like your APC)  - in an
application you will have (say)
system properties -> command line -> some user
properties -> your groovy container needing config
( roder of config containers may vary, depending on
your view what should be default / override) 

This way config nodes go away altogether. 
When you need to depend on property (config entry) 
you shall use ConfigParameter - it is like component
parameter with explicit key, but converts string to
desired class ( if possible  - it can also bomb if
parameter  value is non-parsable ) 

And this will eliminate  need for "use names"
( simplifying vanilla component parameters)

In code:
  PC sysprop = new SystemPropertiesPicoContainer();
  PC commandline = new CLIPicoContainer(CLI,sysprop):
  PC attriibuted = new APC(String[],commandline);

now config is in place.

  PC workContainer = new PC(attributed);
 
workContainer.addComponent(NeedString.class,[ConfigParameter("foo.bar.baz")])

nice groovy syntax would be also possible ( 
you are better at it than me ) 


It would be nice to XML too:
<component key="bla" class="NeedString">
   <config>foo.bar.baz</config>
   ...
</config>

and, while we are at it, why not simplify parameter
even more bu splitting "by class" and "by key" modes? 
( "use names" is kind of  config ) 

Anyway, your current implementation of APC only
supports string / integer / boolean - there is much
more interesting config stuff. ( files, streams,
urls... ) 

WDYT?

regards,

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


       
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

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

    http://xircles.codehaus.org/manage_email