> the first strategy is to allow the subcomponents to configure > themselves > using bean-like rules. the idea is that the object to be > configured must > conform to certain patterns similar to getters and setters for the > xml->object mapping. (xo and betwixt in the commons-sandbox > were created > with this philosophy in mind.) > > this strategy has the advantage of being more secure and > offers less room > for configuration conflicts. it's also much easier to explain to an > implementor that these are the rules that their beans need to > follow to > make the configuration work properly than it is to say - go > learn digester.
I like this idea (regardless of whether digester is used to implement it) because as mentioned, it would be relatively easy to document what a developer would need to do (name methods in a certain pattern?) to make their component "dynamic configuration" enabled. I also think it could be applied to multiple/different configuration file formats, not just the xml format. But I would like to work out an example. -Mark -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
