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 [mailto:[EMAIL PROTECTED] 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("[EMAIL PROTECTED]"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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
