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 01:11:49 GMT
On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching <> wrote:
> > I was also wondering, there may be occasions where it is desirable to
> > have the full body *including tags*  passed in a call back. This would
> > mostly apply in mixed context tags where text is mixed with style
> > information that do not need processing like with XTHML.
> You mean stringify the child elements too, like XSLT does if you ask for
> the text of a mixed-content element?

> I suppose we could do this, though I am not entirely sure how much use
> this would be. Can you think of a use-case?

Think of the transformation of our web pages. There is structure
information wrapping pure XHTML. You would not want a callback for all
formatting tags, would you? Maybe this is not a very common use of
Digester, though...

> If you mean pass a DOM tree into the Action to represent the "full body"
> content, I think not :-).

Certainly not. I think there is no place for the DOM in Digester.

> > > Or are you by chance referring to my suggestions for xml-rules?
> >
> > No, what are they?
> I was puzzled about your reference to "reflection" in the previous
> email, as accessing Rule (now Action) classes is never done via
> reflection. However in the RELEASE-NOTES.txt I do discuss possible
> updates to the classes in the xmlrules package to use reflection to make
> Action classes accessable via the xmlrules mapping file rather than have
> the xmlrules java code contain an explicit mapping class for each Action
> as is currently done.

Is that so? I have no internal knowlede of beanutils, but I thought
there is no other way of calling a parameterized method than by
refelection methods. But I am happy to learn something here :)
> >
> > > >
> > > > If so I would be more than happy to abandon xmlio (in) as - apart from
> > > > philosophical considerations - it would be superfluous and I would
> > > > offer development support for digester if that is welcome.
> > >
> > > You would be very welcome indeed to work on digester if you wish.
> > >
> > > My memory of our discussions about xmlio/digester is a little vague now,
> > > but I remember coming to the conclusion that their concepts were
> > > different in some fundamental ways. If we *can* find some way to merge
> > > the two projects, though, I'm all for it. Does the fact that Digester
> > > and SAXHandler have been split apart make this possible now?
> >
> > Honestly, I do not remember much of that discussion, but I thought we
> > came to the conclusion that we would try to make xmlio obsolete with
> > Digester2. The reason I preferred xmlio over digester was simplicity
> > and obviousness mainly. Now this new Digester2 core (even better with
> > the Action subclasses in a package of their own) is simple and obvious
> > as well, so I see no strong reason to stick to xmlio.
> That would be very cool.
> I remember the main issue being that Digester is built around the
> concept of having patterns control what operations were executed for
> each xml element, and having the invoked logic partitioned into many
> small Rule classes.
> You wished the user to write a big switch statement in Java to determine
> what operations were executed, as you felt that this was more natural to
> people used to writing SAX code by hand.
> We did briefly discuss ways of layering the code so that these were two
> possible options the user could choose between, but I couldn't see then
> how this would be possible.

Thanks for reminding me of my reservations :) Now I remember!
Especially when writing rahter simply import code I think it is much
easier and obvious to have all the code at one position instead of
having it distributed into many classes. However, this seems to be
rather simple to accomplish. You just register a single action to be
matched for all elements and then access the context to tell you the
path of the current element. Maybe having a conveniece method to match
paths to the current element directly.

Wouldn't this work?

Speed is another issue with xmlio, as it is really fast. But with some
optimizations geared towards this, digester shoudn't relly be much
slower anyway...
> If you can think of some way of merging these quite different
> approaches, I'm very keen to hear it. Or if you feel more kindly toward
> a "distributed" pattern-matching + Action class approach, then that
> would resolve the major issue and we can look at how the other xmlio
> features could be provided in Digester (well, we can do that anyway!).

Are you thinking of the export features?

Thinking of the import features, having more than one actions being
invoked on a certain element would be essantial. Just think of some
sorf of logging or debugging action that is triggered with every
element next to the normal processing. Does this currently work with
digester 2?


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

View raw message