Hi Simon! On Thu, 03 Feb 2005 23:57:30 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote: > I look forward to seeing your ideas on stringifying trees of elements.
Isn't it about time to give Digester2 a place in SVN, so I can either create patches against it or directly commit to it. What about a branch in commons proper? Or at least the sandbox? > > > 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... Agreed. Maybe a commons component of its own? Very small code, but reasonable in scope. Many people need XML printing.... Thoughts? > > > > > 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. Agreed. > 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 When you populte beans or call methods on classes I would agree it rather is a hazard. But if you think of an XML document as some sort of message why shouldn't be there more than one part of a complex system that is interested in it? I need to think this over. Maybe it is time to do some coding and experiments now.... > 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? Hmmm, using SAX it always is a bit tricky to get a good idea how your XML document that is being parsed *really* looks like. commons-logging is no good in that case. If you have something that collects the whole document and regenerates it this can be a very valuable debug information. Consider the stuff you parse is not in your file system, but comes from a stream from a remote server it isn't all obvious what is looks like. > 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. I understand what you say, but do not understand why a new list would have to be build with each match call. Why can't you statically addd the "always present" action into the list? Coul you explain? Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
