Stephen Colebourne wrote:
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?)
Stephen
a) and b) is fine with me. The discussion about the class name I will
leave to you native speakers ;-)
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
