(i've had a look but i need a bit more time to think before i comment on the actual patch)
i suppose that i should state my general feelings on the issue of 'how to deal with extensible object models'. in general, i agree with jason approach. the 'right' way is to have a list of reasonable assumptions about how object mapping should work and then support parsing of object's that match these rules through a general 'fall-back' ruleset. (this simple a set of rules that have very short matching keys and so can always be over-ruled by specific rule match). any object which follows these general rules will be mapped correctly. jason and i have - slightly incompatible - working prototypes (jason uses dom4j and i use digester) of this kind of set up. of course, this will not solve your particular problem since introducing general fall-back rules would require changes to tomcat. in the long run, though, i think that this system would be more intuitive to code and easier to maintain than relying on people being able to correctly code self-configuring objects. - robert On Wednesday, December 12, 2001, at 11:35 PM, Mika Goeckel wrote: > Hi! > > Is it possible to add rules to the ruleset of a digester after the parse > has been started? > The reason for that is, that it would enable us to put the knowledge > about child objects within something like a configure() method of a just > created object. > > For example if someone creates a complicated valve with subobjects in > tomcat, the knowledge that a valve needs to be created is for example in > org.apache.catalina.startup.ContextRuleset. > Now if someone needs a Valve with subobjects configured via digester > he/she has to change the ContextRuleset class. > > If it would be possible to call a configure method on the specific > implementation of a class, it could itself add the rules for childs. > > A class could implement a ProvideRules interface defined in the digester > package to let the digester know that it wants to provide additional > rules. > > Comments please? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
