On 24 Nov 2003, at 22:54, Simon Kitching wrote:
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); }
and
Digester.setVarExpander(VarExpander varExpander)
a little. i was using interface in the modelling sense (which you'll probably have guessed will mean that i'm going to make it an abstract class since it'll probably need to be expanded in the future).
abstract class ReplacementStrategy {
public abstract Attributes replaceAttributes(Attributes baseAttributes);
}
with a getter and setter. the actual interface is still a little fluid in my mind at the moment. the name might also change.
so that the user can control exactly how variables are detected in strings, and how the replacement data is located?
that's pretty much right.
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
approach.
i was planning on making the default no substitution :)
this will preserve backward's compatibility.
remy's will be the headline (or basic) substitution implementation.
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.
i was planning to use something along those lines. lazy is probably good but maybe need to think about caching results. i think that we should be able to re-use the same instance without worrying about re-entancy (but i'll need to double check that tommorrow).
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 know.
it was just a comment :)
i'd like to see support for this in the core digester implementation (rather than in a subclass).
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
