commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <>
Subject RE: [lang] VariableFormatter issues
Date Tue, 25 Apr 2006 15:06:46 GMT

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

Would changing MapVariableResolver only do the trick?

The implementation in the ticket subclasses VariableFormatter, why not
subclass just MapVariableResolver only?

To make the code more reusable we should be open to making the inner
classes stand alone.


> Sent: Tuesday, April 25, 2006 7:05 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] VariableFormatter issues
> Gary Gregory wrote:
> >>-----Original Message-----
> >>From: Henri Yandell []
> >>Sent: Monday, April 24, 2006 12:12 AM
> >>To: Jakarta Commons Developers List
> >>Subject: [lang] VariableFormatter issues
> >>
> >>Our favourite 'will this become a templating language' class.
> >>
> >>Two issues to ask questions about:
> >>
> >>1) First enhancement request: #36873. Adds MessageFormat like format
> >>patterns. It's an enhancement, seems like a pretty good one to me as
> >>it is an enhancement that builds on the JDK and not a new feature.
> >>does this sit on people's slippery slopes?
> >
> >
> > This is interesting and slippery. Since the submitted code uses
> > "MessageFormat.format", we are not inventing a language, just
> > a JRE feature.
> >
> > OTOH, the class VariableFormatter is named as such *because* it is
not a
> > "Format" subclass and was not intended to be. So providing "Format"
> > features via a subclass to VariableFormatter is clean in the sense
> > we are not mixing things up but not really what I had in mind
> > the great part about OS). OTOH (the OOH), if we really think this is
> > fantastic feature, we should consider if it should be better
> > than with a subclass.
> >
> > I like VariableFormatter the way it is. So I am neutral as to using
> > submitted code. If we do use "VariableFormatterWithFormating", could
> > consider better class name?
> >
> Well I like it (maybe because I've submitted it) and use it frequently
> in my source codes. I wasn't really happy with the name too, still in
> idea you don't need a sub-class a better idea would be a flag passed
> turns on/off formatting but on the other hand this would maybe blow up
> the numer of API-Functions.
> Tom

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

View raw message