On Tuesday, May 14, 2002, at 10:11 PM, Mark Womack wrote:
>> 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. digester's just a SAX wrapper. given a little effort, you can do nearly anything with it :) self-configuration is more powerful and there may be circumstances where that extra power is needed. a good example is when you want to have in your configuration graph objects whose signatures cannot be changed because they were not created by yourself but which don't meet the rules. it doesn't really have to be an either/or situation. there's no reason why both approaches shouldn't be supported so long as there's a demand. > 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. sounds interesting, i'd say. - robert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
