Hi Oliver,
On Wed, 2005-02-02 at 15:22 +0100, Oliver Zeigermann wrote:
> On Wed, 02 Feb 2005 14:48:42 +1300, Simon Kitching <[EMAIL PROTECTED]> 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?
Well, I would prefer to avoid having users do:
addRule(new Pattern("/foo/bar"), ....)
as this is just more readable:
addRule("/foo/bar", ...)
However if we ever do find that there are some patterns that just can't
be represented nicely as a string, then we could simply add a new
method:
addRule(Pattern p, ...) { ....}
and reimplement addRule to preserve compatibility:
addRule(String s, ... ) { addRule(new Pattern(s), ...); }
So in short, I would prefer [1] to keep the current String pattern as
one of the options, for user convenience, but I don't see any major
issue with adding Patterns later if we need them. I guess it would break
custom subclasses of RuleManager, but that would be a very rare thing to
do.
And right now, DefaultRuleManager definitely needs its patterns to be
strings, so if we had a Pattern class as the pattern, we would be
forcing users to create an instance just so the DefaultRuleManager could
turn it back into a string.
>
> > > - I like the bodySegment vs. body design :)
> > Cool. Now I just have to implement it :-)
>
> Ooops, doesn't it work, yet?
Minor detail. I just need to merge the code from the example I
referenced into the core. Why are there never enough hours in a day?
>
> >
> > 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.
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?
If you mean pass a DOM tree into the Action to represent the "full body"
content, I think not :-).
> > > - 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.
Yes, I remember that thread. I'll re-read it.
> > 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?
Suppose digester requires beanutils 1.7, but a user wants to call
digester from an app that is using beanutils 1.6 (or 1.8) or similar,
and the beanutils lib versions are incompatible.
In this situation, the user is currently out of luck (or at least there
is no documented solution).
But using classloaders it is possible to access classes different from
the classes available to other parts of an app. For example, webapps in
tomcat have their own private libs that are not available to either
tomcat or sibling webapps. Using this sort of trick, we could arrange
for digester to access all the beanutils classes via a user-provided
classloader, which accesses a beanutils-1.7.jar that is not in the
classpath for the rest of the app.
I haven't really thought about this in detail; it's just an idea at the
moment. I'm vaguely envisaging a method
Digester.setLibraryClassLoader(ClassLoader cl)
or
Digester.setLibraryClasspath(String customClasspath)
It might end up better to load the whole of Digester in a custom
classloader, in which case the problem is pushed back up to the user
domain; all we would need to do is document how to do this rather than
actually add any custom code.
>
> > 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.
Well, it's done. I hope to post the new version later today.
>
> > 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.
>
> > >
> > > 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.
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!).
Cheers,
Simon
[1] Of course the decision is by consensus, not my preference!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
