commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <>
Subject Re: [digester] initial code for Digester2.0
Date Thu, 03 Feb 2005 22:36:14 GMT
Hi Simon!

On Thu, 03 Feb 2005 23:57:30 +1300, Simon Kitching <> 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....

> >
> > > 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

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?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message