Stephen Colebourne wrote:
Oliver Heger wrote:
+1 for the name StrSubstitutor.
:-)
Well, I guess I have no chance to convince you to get back to Object
as result type for the resolver interface? Hm, for [configuration] I
can probably live with this, but it may cause unnecessary conversions.
My review of the original code seemed to show that if there was one
substitution then the input object was returned, but if none or two
substitutions then the string was returned. This just seems like a plain
weird API.
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?
Stephen
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.
But maybe you are right and this concept is not really stringent.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
