commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [lang] VariableFormatter - pre 2.2
Date Tue, 01 Aug 2006 23:55:07 GMT
>> For example "There were ${number} characters", would return the object 
>> matching the ${number} substitution, and dropping the rest of the text!
>> Perhaps you can point to an exact use case?
Oliver Heger wrote:
> Your analysis is correct. The idea was that you can have specialized 
> resolver implementations that inherently work on objects, e.g.
> - a constant resolver, which interprets the variable name as a name of a 
> static field of a class, e.g.
> ${my.package.MyClass.MY_CONSTANT} would return the value of the constant 
> field.
> - an expression resolver, which could be passed an expression in a 
> language like JEXL and would calculate the result.
> Of course if the string passed to the substitutor contains other text 
> elements or variables, you have no choice than converting the result to 
> text. But if only a single variable is to be processed, the result can 
> be an arbitrary type.

Sounds a bit [configuration] specific to me.

However, we could add a singleVariableName(String) method which would 
check for the special case where the whole string was a variable.

We could also have a variableNames(String) method which returns the top 
level variable names in the string.

Not sure how useful either of these would really be though.

What might be more useful, would be to change the method signature of 
resolveVariable() to take the StrBuilder start pos and current variable 
start and end. That would effectively provide subclasses with much more 
detailed events about the variables.

So, pre 2.2 - I'd suggest
a) alter resolveVariable()
b) extract VariableFormatter interface to be StrLookup abstract class
c) agree class name (is anyone not OK with StrSubstitutor?)


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

View raw message