commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [digester] [PATCH] Adding Ant-like properties support
Date Mon, 24 Nov 2003 22:54:45 GMT
On Tue, 2003-11-25 at 11:32, robert burrell donkin wrote:
> i've finally found time to consider both proposals (apologies for the  
> delay).
> 1. i think that i like some parts of remy's solution but would prefer  
> the actual implementation to be pluggable through a strategy interface  
> (probably implemented as an abstract class). i know that this is a  
> little slower but i think that in the long term, it's better for  
> digester not to be tied to a particular implementation (no matter how  
> good ;)

Could you expand on this "strategy interface" a little, Robert? I'm not
quite sure what you mean here.

Are you suggesting something like this?
  interface VarExpander {
    /** expand any variable references in the string */
    String expand(String raw);


Digester.setVarExpander(VarExpander varExpander) 

so that the user can control exactly how variables are detected in
strings, and how the replacement data is located?

That sounds good to me. The default could be Remy's implementation which
requires the syntax ${xxx} and which always draws from one source. My
suggestion of an "enhanced" version that allows more flexible variable
"detection" and multiple sources could be provided as an alternative
[provided anyone thinks it is useful enough to add to the Digester
base]. This seems symmetrical with the BaseRules/ExtendedBaseRules

> 2. i think that simon's correct that the right place to do this is in  
> digester rather than in particular rules. coding this into rules is  
> just going to cause confusion for users and difficulties when some  
> rules support it and some don't.

I was actually working on this last night. I've come up with the idea of
a "lazy evaluation" wrapper for the org.xml.sax.Attributes class, which
only checks attribute values for variables when the attribute value is
asked for. 

I hope to be able to post this to the list in about 24 hours time.

This hopefully solves Remy's (quite correct) objection about performance
with the code I originally posted.

> 3. i'd prefer not to subclass and instead use a seamless substitution.  
> i'd probably start with just the attribute values and provide just the  
> behaviour in remy's post.

Is this in reference to the implementation I posted which subclassed
Digester in order to provide this functionality? That was never intended
to be a final solution; it's just what I currently have in production.
For production code, I don't like modifying libraries :-). I agree that
var expansion should really be integrated into the existing digester
stuff without subclassing Digester.

The stuff I posted wasn't a prepared patch; I just grabbed some stuff I
already had floating around and sent it out as an alternative
suggestion. Sorry if that wasn't clear.

If you meant something else by "prefer not to subclass" please let me

> 4. for the stock implementation of the strategy, i'd like to use remy's  
> algorithm.
> 5. extra features (and more flexible behaviour) can be added later as  
> necessary.
> remy - is there any chance of a unit test (or two) so that i can ensure  
> that implementation hasn't missed anything?
> i'll hold off starting this till tommorrow so other people have a  
> chance to comment (and find any holes in my logic ;) before i start  
> work.
> - robert

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

View raw message