Tom Schindl wrote:
>Gary Gregory wrote:
>
>
>>Hello:
>>
>>I wonder if in the interest of getting version 2.2 out the door we
>>should keep VariableFormatter as-is. Anyone who likes the subclass can
>>obviously use it. If the feature is easy to add, we don't have to
>>discuss the following for post-2.2:
>>
>>- Does the VariableFormatterWithFormating functionality belong in
>>VariableFormatter or should it be a subclass.
>>
>>- It seems like we could also extend the current ${} syntax to include
>>the VariableFormatterWithFormating feature. Where this gets tricky and
>>could become difficult is if we cannot reuse MessageFormat.format.
>>
>>Tom (and all):
>>
>>Have you considered changing VariableFormatter itself to provide the
>>feature?
>>
>>
>>
>
>Yes but I thought if you want to turn on/off variable formatting (e.g.
>because of performance issues) the API would get too bloated, you need
>to duplicate all static functions, wouldn't you?
>
>
>
>>Would changing MapVariableResolver only do the trick?
>>
>>
>>
>
>Yes, I think so but I wasn't sure about the side-effects.
>
>
>
>>The implementation in the ticket subclasses VariableFormatter, why not
>>subclass just MapVariableResolver only?
>>
>>
>>
>
>Because of the above mentionned bloated API if you want to turn it
>on/off in VariableFormatter.
>
>
I think part of the problem is that many method signatures expect a Map
and convert this automatically into a MapVariableResolver (e.g.
constructors of VariableFormatter, static replace() methods). This is
convenient for the users that only need the default functionality, but
makes it hard to use a different VariableResolver implementation.
Shouldn't we at least have static replace() methods that take a
VariableResolver as argument? Then a caller can decide if he/she wants a
default or a formatting enabled resolver.
Oliver
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
