commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <oliver.zeigerm...@gmail.com>
Subject Re: [digester] initial code for Digester2.0
Date Wed, 02 Feb 2005 14:22:56 GMT
On Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching <skitching@apache.org> wrote:
> > - Wouldn't it be possible (and even desirable) to have a more general
> > Pattern class instead of a String in Digester#addRule?
> Can you explain more?

Well, RuleManager is an abstract class (discussion abstract class vs.
interface applies here as well) with a default implemenation, but
Pattern is a String. Wouldn't it be more flexible with little extra
cost to have a Pattern interface with a default String Path
implementation like the current one?
 
> > - I like the bodySegment vs. body design :)
> Cool. Now I just have to implement it :-)

Ooops, doesn't it work, yet? 

> 
> The inspiration can be found in the digester 1.6
> "src/examples/api/document-markup" example, where the code has to go to
> great lengths to handle XHTML-style input.

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.

> > - I like the no dependency and digester2 package approach
> 
> Ok. I really thought people wouldn't like "o.a.c.digester2". In fact,
> I'm not sure I like it myself. The main reasons are:
> (1) that I don't know any other projects that do this. Tomcat, struts,
>    commons-collections, etc, don't do this.

Tomcat does not need to as it is no library. commons-collections
should better have done this - for more details have a look at the
thread all this was discussed in recently.

> (2) that upgrading an application using digester 1.x to digester2.x
>     requires changes to all the import statements.

I understand Digester2 is incompatible to 1.x anyway, so changes to
the import statements aren't the primary problem, right? If it was
fully compatible, there would be no need to call the package digester2
anyway.

> As noted, there is still currently a dependency on BeanUtils; digester
> uses too much from that package to copy the classes into digester. But
> as noted I would like to experiment with accessing BeanUtils
> functionality via a custom classloader so that if people have problems
> with clashing lib versions there is a solution.

Could you elaborate this?

> I quite like Emmanuel Bourg's suggestion of an "actions" subpackage to
> hold the subclasses of Action, which would show that they aren't tightly
> coupled to the Digester "core" classes.

That's exactly what I would want to see. 

> Or are you by chance referring to my suggestions for xml-rules?

No, what are they?
 
> >
> > 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.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message