Hi Oliver,
On Tue, 2005-02-01 at 18:04 +0100, Oliver Zeigermann wrote:
> I very much like that and think it really is straight forward.
>
> Comments:
> - Why is Action an abstract class?
So that we can later add new functionality to Action without breaking
custom Action subclasses that users have written. As long as we can
provide a suitable default implementation in the Action abstract class,
everything runs smoothly.
One example is the "bodySegment" callback that is now in Action. In
Digester 1.x we could not have added this to Rule without breaking all
custom Rule classes. But if digester2.0 had been released without it, we
could have added it later with no source or binary compatibility
problems.
Of course because of Java's single-inheritance policy, it would be
impossible for a class to extend both Action and some other class. But
(a) this is extremely unlikely, and (b) using an "adapter" class works
around this anyway if it absolutely has to be done.
> - 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?
> - I like the bodySegment vs. body design :)
Cool. Now I just have to implement it :-)
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 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.
(2) that upgrading an application using digester 1.x to digester2.x
requires changes to all the import statements.
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.
> - It's no secret that I am no fun of reflection stuff: is it really
> necessary to have the subclasses of Action be part of the *very*,
> *very* digester *core*?
Sorry, I don't follow this. Could you explain?
One thing the proposed code does do is separate ActionFactory from
Digester, so the Digester class doesn't have compile-time dependencies
on any Action subclasses.
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.
Or are you by chance referring to my suggestions for xml-rules?
>
> 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?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
