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 18:09:39 GMT
i've had a longer think about this, and i'm not really sure anymore 
that there's any XPath engines that this would work for. the other 
issue is that some XPath expressions really require the whole of the 
document to work with. (but scott would probably know better than me if 
this is feasible so if he's lurking, i'd be interested to hear his 

in terms of adding support for attribute matching, i'm a little 
reluctant to consider modifying the matching string syntax but i 
suppose that we could add a wrapper rule (even though it's not a very 
elegant solution).

the current design for Rules makes it easy to create new rules 
implementations but is limited by the amount of information available 
to the implementation. the string syntax passed into the call is the 
limiting factor.

this has set me wondering whether something like XSLT would be a cool 
to map XML to objects. rather than templates, rules would be applied to 
the products of XPath expressions. xml rules could probably be mined 
but still would be a lot of work.

- robert

On 11 Apr 2004, at 14:31, robert burrell donkin wrote:

> 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 
> 1.
> - 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:

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

View raw message