[picocontainer-dev] Nano2 (baby steps - work in progress) 'config' based entries in component tree.

Pico2 can now satisfy ....

     class UberPersistenceLayer {
         public void  UberPersistenceLayer(String jdbcUrl, String  
jdbcName, String jdbcPassword) { ... }
     }

... without throwing an AmbiguousComponentResolutionException cos  
there are three strings and it all looks a bit confusing.  That's  
because Pico leverages Paranamer to get the names of the args, and  
provided there are components in the container (or parents) that  
satisfy named keys of "jdbcUrl", "jdbcName", "jdbcPassword" it will  
work.

In terms of NanoContainer, should we allow an additional grammar for  
named parameters like so (Groovy):

   container {
       config(name:"jdbcUrl", value:"jdbc:derby/bar/foo/etc")
       config(name:"jdbcName", value:"admin")
       config(name:"jdbcPassword", value:"ferret")
       ....
       container {
           component(key:PersistenceLayer, impl: UberPersistenceLayer)
       }
       ....
   }

Or like so:

   container {
       const(name:"jdbcUrl", value:"jdbc:derby/bar/foo/etc")
       const(name:"jdbcName", value:"admin")
       const(name:"jdbcPassword", value:"ferret")
       ....
       container {
           component(key:PersistenceLayer, impl: UberPersistenceLayer)
       }
       ....
   }

Or like so (as is today):

   container {
       component(name:"jdbcUrl", value:"jdbc:derby/bar/foo/etc")
       component(name:"jdbcName", value:"admin")
       component(name:"jdbcPassword", value:"ferret")
       ....
       container {
           component(key:PersistenceLayer, impl: UberPersistenceLayer)
       }
       ....
   }

I prefer config (in addition to component) as it reminds us that  
Inversion of Control is three things - dependency, lifecycle and  
configuration.  I think that const is grammar for 3GL languages as  
opposed to the mini-DSL for composition/deployment that NanoContainer  
is.  Maybe we could do all three pretty cheaply.

Thoughts?

- Paul





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

    http://xircles.codehaus.org/manage_email