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. > To make the code more reusable we should be open to making the inner > classes stand alone. > That would be a great thing to have. > Gary > I think adding this formatting to VariableFormatter makes it more useable e.g. for displaying debugging messages than it would be now. Tom
signature.asc
Description: PGP signature
signature.asc
Description: OpenPGP digital signature
