On Thu, 03 Feb 2005 15:38:30 +1300, Simon Kitching <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-02-03 at 02:11 +0100, Oliver Zeigermann wrote:
> > On Thu, 03 Feb 2005 11:39:01 +1300, Simon Kitching <[EMAIL PROTECTED]>
> > 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?
> >
> > Yes.
> >
> > > 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...
>
> Ok, I see. It would be reasonably simple to implement; we already
> calculate the full text for each element (so we can pass it to the body
> methods) in the SAXHandler class; we just need to keep appending these
> instead of discarding them when the element ends.
>
> One issue, I guess, is that by the end of the document we have a
> StringBuffer that contains the entire text for the entire document -
> which might take up a bit of memory. So maybe we need some mechanism for
> an Action to tell the SAXHandler [from its begin() method, via a mixin
> interface, or otherwise] that it wants a full text tree. The SAXHandler
> can then start accumulating.
>
> If you wished to contribute such a patch, I think I'd be in favour of
> it.
I agree and will contribute such a patch. I will think about such a
mechanism and will discuss it as soon as I have something.
> > 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 :)
>
> Just some minor misunderstanding I think..
>
> The digester framework invokes Rule (Action) classes directly. There is
> no reflection involved in the invocation of Rule (Action) classes.
I know. But I was thinking of ActionCallMethod having code like
Object result = MethodUtils.invokeMethod(
target, methodName,
paramValues, paramTypes);
Isn't that done by reflection?
> I am proposing that xmlrules actually uses reflection to generate a set
> of Action objects when parsing its rule configuration input file. Of
> course the parsing of the actual user input would then be done in the
> normal manner (with the digester framework calling the Actions
> directly).
>
> The Rule (Action) classes interact with domain-specific (user) classes
> via BeanUtils and reflection. I don't see any alternative, except for
> the "pre-processor" type xml mapping tools, or runtime bytecode
> generation, neither of which are really Digester's domain.
Well, there it is, my reflection. So we had a misunderstanding. The
options you name are worse than refelection, I agree, but why using
the BeanUtils in the first place? Isn't plain refelction sufficient?
> > >
> > > 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?
>
> Hmm.. If we had a class that implements RuleManager that always returns
> a custom Action no matter what the path, then all events would be
> forwarded to the user-provided action, where the user can call
> context.getMatchPath()
> to access the current path, and determine from there what operations to
> perform.
>
> // xmlio-style digester
> Action myHandler = new AbstractAction() {
> public void begin(
> Context context,
> String namespace, String name,
> Attributes attrs) {
>
> String path = context.getMatchPath();
> if (path.equals("......")) {
> ....
> } else {
> ....
> }
> }
>
> public void body(...) {
> }
> }
>
> RuleManager xmlioRuleManager = new XMLIORuleManager(myHandler);
> Digester d = new Digester();
> d.setRuleManager(xmlioRuleManager);
>
> Thoughts?
Looks good. However, we would need code that does the same as the
default rule manager in getMatchingActions to match relative paths as
well. xmlio uses the same path syntax as digester2 anyway.
I will provide something for this as well.
> > > 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?
>
> No, just wondering in general if there is stuff that can be merged.
I will check which internals or options can be taken over. In general
the xmlio trick was not to have too many features to be easy to use.
> 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.
> 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?
> Thanks by the way for all your comments. It's great to know other people
> are interested in a digester2...
Thanks for taking them seriously and letting me participate in the
Digester2 design :)
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
