avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Tagunov" <atagu...@list.ru>
Subject Re[2]: MutableConfiguration - I feel an issue
Date Tue, 10 Feb 2004 16:12:41 GMT
Hi, Aaron!

AT> void amendConfig( final MutableConfiguration node )
AT> {
AT>     final DefaultConfiguration b1 = new DefaultConfiguration( "b" );
AT>     b1.setValue( 1 );
AT>     final DefaultConfiguration b2 = new DefaulcConfiguration( "b" );
AT>     b2.setValue( 2 );
AT>     node.addChild( b1 );
AT>     node.addChild( b2 );
AT> }
AT> And I thought we would got rid of the dependency on DefaultConfiguration!

AAF> There is no dependency on DefaultConfiguration.  Notice:

LSU> addChild(Configuration config)
AAF> implies that you can use any Configuration implementation.  

..hmm, maybe this is the reason! I somewhat do not buy the idea:
are we going to have a mixed tree?

      |                                    |
   ConfigurationBBB                ConfiguraitonCCC

so it is my amendConfig() method that decides what kind of config
to append?

Need to swallow this!

What I imagined was that there would be some factory to
get MutableConfiguration instances from (perhaps supplied in the IoC
mannger) and then we would rely totally on the obtained
instance to grow the tree, like

interface ContainerExtension
     void amendConfig( MutableConfiguration mc );

class MyContainerInternals
    MutableConfigurationFactory m_mcf;
    ContainerExtension m_extension;

    void launchComponent()
        MutableCofiguration mc = m_mcf.newInstance();
        m_extension.amendConfig( mc );

class MyContainerExtension implements ContainerExtension
    public amendConfig( MutableConfiguration node )
         MutableConfigration b1 = node.createChild( "b" );
         b1.setValue( 1 );
         MutableConfiguratin b2 = node.createChild( "b" );
         b2.setValue( 2 );

this way MyContainerExtension has not dependency on _any_
configuration implementation. And the tree is homogenous.

This is why I was talking about issues. But is our use case
different? Do we instead have heterogenous tree and each
container extension is free to plug in any implementation
it likes? Hmmm..


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message