commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Digester and attribute matching?
Date Sun, 11 Apr 2004 13:31:35 GMT
this may well be completely left field but...

i wonder whether it might be possible to use SAX pipelining to add 
XPath support. rather than changing digester, create a filter that 
splits the SAX feed and sends one copy to a special engine and another 
direct to standard digester. the special engine could then use a 
standard SAX-based XPath implementation.

the only problem is what is i think is (with hindsight) the major flaw 
with the current design: rule implementations have a dependency on 
digester rather than an abstract, minimal RulesEngine. so (sign) it 
would probably be a bit of hack to do this kind of thing with digester 

- robert

On 9 Apr 2004, at 21:07, Chen, Tim wrote:

> Thanks Simon :)
> I just recently started using Digester so I don't yet know enough 
> about it's
> innards to make a change to it but I'll definitely keep that in mind :)
> -Tim
> -----Original Message-----
> From: Simon Kitching []
> Sent: Friday, April 09, 2004 4:04 AM
> To: Jakarta Commons Users List
> Subject: Re: Digester and attribute matching?
> On Fri, 2004-04-09 at 04:36, Chen, Tim wrote:
>> I saw that in the list archives it was not supported but
>> 1) is it planned to be able to support something like
>> digester.addCallMethod("foo[@bar=\"blah"\]", "foo"); ?
>> 2) is there a way around it currently?
>> I see that all the rules have a way to see the attributes before
> processing
>> but I don't know how to stop that rule from processing.
> No, there is no support for this kind of conditional matching in
> Digester.
> I can see that it would be nice for digester to have it, but I wouldn't
> have a clue how it could be implemented (efficiently and elegantly). It
> isn't planned any time in the near future, because as far as I know,
> none of the current Digester developers have a need for this feature.
> I've got it as a bullet-point for consideration for Digester-2.0. but
> that could be quite a while away (if ever).
> But that's where the power of "open source" comes in - if you want the
> feature, please feel free to implement it. If you can come up with some
> proof-of-concept code that shows how this could be done in Digester,
> then I (and I'm sure others) would be very interested. I am happy to
> (try to) answer any questions you have if you do decide to tackle this.
> Note, however, that spending 5 minutes to write some pseudo-code
> probably won't motivate any of the existing regular developers to then
> implement it for you :-).
> I got involved with Digester because I wanted an extra feature,
> implemented it and submitted it as a patch. So from experience I can 
> say
> that contributions *are* welcome.
> If all you want is to prevent CallMethodRule instances from firing if
> certain attributes have certain values, then you *may* get away with
> subclassing CallMethodRule, and storing a boolean flag on the rule
> instance. Set the flag to true/false in begin(), according to the
> attribute values, and then  in body/end methods, just test the flag and
> skip the call if the flag is set. Note that this is not a proper
> general-purpose solution, as it can fail horribly if you use that
> CallMethodRule with patterns containing wildcards. But if that is not
> the case for your application, then you can ignore this issue.
> Regards,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message