Hi Oliver,
On Thu, 2005-02-10 at 19:08 +0100, Oliver Zeigermann wrote:
> Folks,
>
> as I noticed Simon has done so much work on Digester2, I just wanted
> to be sure that my scheduled additions still are appropriate and
> aligned to the overall design. Here they are:
>
> (1) XMLIORuleManager: A rule manager that takes an action and
> unconditionally calls it on any event. It's useful to imitate xmlio
> style processing, but not limited to this. One application might be
> logging. As it is more general any proposal for a better name?
>
> Quoting code sample from Simon:
>
> > // 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);
> >
>
> As an option it might be possible to register an action with any rule
> manager that gets called unconditionally - epsecially for logging and
> debugging this can be really helpful. However, I wasn't quite sure if
> Simon was happy with that.
>
Adding functionality to DefaultRuleManager that returns a set of default
actions *if no other action matches the current path* is not a problem.
I'm all for it. And this would meet your requirements, yes? So I'm happy
for you to go with this if you agree. And as a bonus, implementation
should be trivial: a dozen lines or so. I'm not sure whether this API
should then be exposed via the RuleManager interface (ie required for
all RuleManagers) or just left on DefaultRuleManager.
Adding functionality that returns a set of actions *in addition to* the
actions that match the current path is trickier. In what order are they
returned? And can we avoid instantiating a new List object each time
getMatchingActions is called? I'm not saying I'm opposed to it, I'm just
not sure right now.
> (2) Next to the body and bodySegment call back methods there might be
> one that gives you the complete body of an element as a string
> composed of all character and markup data. This might be useful when
> you want to verbosely take over formatted mixed content like in XHTML.
>
> For performance reasons there should be some mechanism that tells
> digester when such content is needed on an element basis. Maybe
> something returned by the begin method or - maybe cleaner - something
> returned by an additional call back directly called after begin like
> boolean requiresComposedBody(String namespace, String name) or
> anything similar. This method could alternatively be part of an
> additional or extended interface.
Yep. I'm in favour of this. I would prefer an eye to be kept on
performance; the "requiresComposedBody" solution doesn't tempt me
greatly as that is a call that must be made on each Action each time it
matches, and 99.999% of those calls will return false. I could live with
it if there is no better alternative. However if an action's begin
method could enable the body text collection and the end method disable
it then wouldn't that have the same effect without additional work when
the feature isn't being used? I agree it's a little less intuitive for
Action writers though...and I haven't thought it through fully.
Note that I am tentatively planning to do some significant rework of the
DefaultRuleManager class. But that certainly won't be for some weeks so
hack away! I guess you'll also be wanting to work on the Path class, so
the custom Action class can more easily test the current path? I'll make
sure I check on this list before altering this class (though I've got no
plans to do so).
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
