Niclas Hedhman wrote:
public class MyComponent {
public MyComponent( MyComponentConfig config ) { // handle config } }
public interface MyComponentConfig {
String getName();
int getSomeValue();
AnotherBean getSomeBean();
}
OK on the above - in fact if you do a search across the Merlin code base for **/*Context.java you will a lot of examples of exactly this sort of thing.
<configuration type="org.hedhman.niclas.MyComponentConfig"> <Name>MyFabulousComponent</Name> <SomeValue>15</SomeValue> <AnotherBean /> </configuration>
It is pretty easy to parse the XML and create a dynamic proxy for the Config object.
And could also have some nice construction semantics for JavaBeans, such as
<AnotherBean type="org.hedhman.niclas.AnotherBean" >
<Level>4</Level>
<TimeSpan>7200</TimeSpan>
</AnotherBean>
Although this is slightly different issue.
I feel really good about coded Config objects instead of the runtime interpreted ones.
Me too.
But it is also really important that the implementation model does not presume XML. Within Merlin this is addressed using a factory pattern. In fact the composition package is structured such you can have different meta-model implementations coexisting in memory - they simply share common APIs on factories, context interfaces, and model interfaces.
Cheers, Steve.
Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
