Hi Oliver, I look forward to seeing your ideas on stringifying trees of elements.
> > > > The Rule (Action) classes interact with domain-specific (user) classes > > via BeanUtils and reflection. I don't see any alternative, except for > > the "pre-processor" type xml mapping tools, or runtime bytecode > > generation, neither of which are really Digester's domain. > > Well, there it is, my reflection. So we had a misunderstanding. The > options you name are worse than refelection, I agree, but why using > the BeanUtils in the first place? Isn't plain refelction sufficient? Well, I don't believe pre-processing is "worse" than digester; it can be a great solution in some situations. And for the rest, there's Digester :-) Digester uses BeanUtils to do type-conversion (via its ConvertUtils component), converting the strings extracted from the xml to whatever types the target methods take. BeanUtils also treats DynaBean classes as if they were normal Java classes, which is needed for at least one very important Digester user: struts. The reflection stuff we use from BeanUtils is only a few dozen lines so I guess we could import that into Digester itself. However the ConvertUtils stuff has a lot of code for typeconversion that I would be reluctant to duplicate. Maybe it's worth having a look at the new "morph" project as an alternative; it's more tightly focussed on typeconversion than BeanUtils. > > > > Hmm.. If we had a class that implements RuleManager that always returns > > a custom Action no matter what the path, then all events would be > > forwarded to the user-provided action, where the user can call > > context.getMatchPath() > > to access the current path, and determine from there what operations to > > perform. [snip] > > > > Thoughts? > > Looks good. However, we would need code that does the same as the > default rule manager in getMatchingActions to match relative paths as > well. xmlio uses the same path syntax as digester2 anyway. > > I will provide something for this as well. Excellent! > > I've not thought too much about obj->xml, and anyway Betwixt has that > > reasonably well covered as far as I know. > > The xmlio out part is much less than obj->xml, but rather a set of > helpers on a low level. It also addresses byte encodings which has not > been thought of in many XML printing solutions. Hmm.. not sure what to do with this code, then. But I'm pretty sure Digester is not the right home for it... > > > If you mean having some debug Action that is triggered *for every > > element seen* in addition to the ones whose patterns actually match, > > then that can be done fairly easily by subclassing a Rules (in > > digester1.x) or RuleManager (in digester2.x) class. I guess we could > > build it in to the default class though... > > This would fit into the xmlio matching above: have an action that is > called unconditionally. This could be useful in many scenarios. > Shouldn't this be part of the default rule manager? > There are usecases for having a set of actions that is returned if no pattern is matched. In particular, it is nice to be able to generate an error, "unrecognised element", if you are very fussy about the input. I would definitely like to add this to DefaultRuleManager. And this feature would fit the xmlio scenario fine. Having a set of actions that are returned *in addition to* any others is possibly more controversial. There was someone looking for exactly that on the digester user list a while ago, wanting to execute SetNestedPropertiesRule for each element. I'm not so convinced this is a good idea, though: seems awful easy to shoot yourself in the foot! Apart from the "debugging" scenario you mention, I can't see a usecase for having an action that is returned *in addition to the other matching actions*. And I generally do debugging by enabling commons-logging output rather than write custom debugging actions anyway. Can you think of some usecases where this would be useful? Note also that currently RuleManager can return prebuilt lists when match is called; no List object needs instantiating. However if "always present" actions have to be inserted into each list, then a new List object is required to be created for each match call. Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
