Discussion:
[Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings
Daniel Dekany
2015-09-13 11:20:14 UTC
Permalink
Because not many people are here yet, it will be lazy vote. Is that
OK? 72 hours to go, unless there will be an active discussion of
course.

We had some RFE-s in past, where someone requested:
- Using half-up rounding mode instead of the Java default half-even
(https://sourceforge.net/p/freemarker/feature-requests/62/)
- Overriding the symbol used for NaN
(https://sourceforge.net/p/freemarker/feature-requests/67/)
- Using dot as decimal separator for certain numbers, instead of
the locale default (which was comma there) (but not the case of ?c)
(https://sourceforge.net/p/freemarker/feature-requests/117/)

I remember some other case (maybe it was just e-mail) where the user
has complained that in general he can't use all the features of
java.text.DecimalFormat as we only allow specifying the pattern
string.

The number format is specified with a string in FreeMarker. This is so
in the Configurable API, also in FTL (<#setting number_format="0.##">
and n?string("0.##")). So I wondered how to allow specifying the
parameters for DecimalFormat without making a mess, and found that we
can just extend the string parsed by DecimalFormat with a new section,
that would cause IllegalArgumentException if you pass it to
DecimalFormat as is, so it's backward compatible to add such a
section.

DecimalFormat accepts almost all kind of random string without
complaining. But it's string about ';'. DecmialFormat allows you to
specify two patterns, one for the positive, and another for the
negative numbers, separated by ';'. We could allow yet another ';' and
a further section, where the properties of the Decimal format can be
specified. So if someone wants '_' for grouping separator and half-up
rounding mode, then instead of ",##0.##", he could use ",##0.##;;
grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
number format) is empty. (This is backward compatible, as that's an
error for pure DecimalFormat.) In general, the 3rd section will be a
list of key=value pairs separated by whitespace and and optional
comma. If a value needs quoting, the quotation rules of DecimalFormat
patterns will be used (i.e, use apostrophe-quote, and double it for
escaping). The allowed keys would be:

- ro=u|d|c|f|hu|hd|he|un: RoundingMode
- mul: Multipier
- dec: DecimalSeparator
- grp: GroupingSeparator
- exp: ExponentSeparator
- min: MinusSign
- inf: Infinity
- nan: NaN
- prc: Percent
- prm: PerMill
- zero: ZeroDigit
- curc: Currency (ISO 4217 Code)
- curs: CurrencySymbol 2nd
- icurs: InternationalCurrencySymbol
- mdec: MonetaryDecimalSeparator

I will add this feature, if you agree.
--
Thanks,
Daniel Dekany


------------------------------------------------------------------------------
b***@me.com
2015-09-13 14:45:32 UTC
Permalink
I vote for the number format extension. 

Note that this may not be forward compatible with future versions of the Java library, since Oracle could well have just the same idea. 

I suggest the keys are open for discussion; I am not sure ‎"ro" for rounding mode is very clear for example. Also how do you decide if the currency symbol is before or after the number?

Cheers,

-- Denis.
  Original Message  
From: Daniel Dekany
Sent: Sunday, 13 September 2015 12:20
To: ***@freemarker.incubator.apache.org
Reply To: Daniel Dekany
Cc: freemarker-***@lists.sourceforge.net
Subject: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings

Because not many people are here yet, it will be lazy vote. Is that
OK? 72 hours to go, unless there will be an active discussion of
course.

We had some RFE-s in past, where someone requested:
- Using half-up rounding mode instead of the Java default half-even
(https://sourceforge.net/p/freemarker/feature-requests/62/)
- Overriding the symbol used for NaN
(https://sourceforge.net/p/freemarker/feature-requests/67/)
- Using dot as decimal separator for certain numbers, instead of
the locale default (which was comma there) (but not the case of ?c)
(https://sourceforge.net/p/freemarker/feature-requests/117/)

I remember some other case (maybe it was just e-mail) where the user
has complained that in general he can't use all the features of
java.text.DecimalFormat as we only allow specifying the pattern
string.

The number format is specified with a string in FreeMarker. This is so
in the Configurable API, also in FTL (<#setting number_format="0.##">
and n?string("0.##")). So I wondered how to allow specifying the
parameters for DecimalFormat without making a mess, and found that we
can just extend the string parsed by DecimalFormat with a new section,
that would cause IllegalArgumentException if you pass it to
DecimalFormat as is, so it's backward compatible to add such a
section.

DecimalFormat accepts almost all kind of random string without
complaining. But it's string about ';'. DecmialFormat allows you to
specify two patterns, one for the positive, and another for the
negative numbers, separated by ';'. We could allow yet another ';' and
a further section, where the properties of the Decimal format can be
specified. So if someone wants '_' for grouping separator and half-up
rounding mode, then instead of ",##0.##", he could use ",##0.##;;
grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
number format) is empty. (This is backward compatible, as that's an
error for pure DecimalFormat.) In general, the 3rd section will be a
list of key=value pairs separated by whitespace and and optional
comma. If a value needs quoting, the quotation rules of DecimalFormat
patterns will be used (i.e, use apostrophe-quote, and double it for
escaping). The allowed keys would be:

- ro=u|d|c|f|hu|hd|he|un: RoundingMode
- mul: Multipier
- dec: DecimalSeparator
- grp: GroupingSeparator
- exp: ExponentSeparator
- min: MinusSign
- inf: Infinity
- nan: NaN
- prc: Percent
- prm: PerMill
- zero: ZeroDigit
- curc: Currency (ISO 4217 Code)
- curs: CurrencySymbol 2nd
- icurs: InternationalCurrencySymbol
- mdec: MonetaryDecimalSeparator

I will add this feature, if you agree.
--
Thanks,
Daniel Dekany
Daniel Dekany
2015-09-13 19:06:57 UTC
Permalink
Post by b***@me.com
I vote for the number format extension. 
Thanks, and that would be "+1 (non-binding)" according the Apache
voting rules. ("Non-binding" because you aren't PMC member...
formality. BTW, if you want to be a PMC member, I'm open to that.)
Post by b***@me.com
Note that this may not be forward compatible with future versions
of the Java library, since Oracle could well have just the same idea. 
Good point. Actually it's forward compatible as FreeMarker will
continue handling that section even then, but I see what you mean. So
either we take this small(?) risk, or we do something like "0.##;;
#ext grp=_ ro=hu", which looks less tidy.
Post by b***@me.com
I suggest the keys are open for discussion; I am not sure ‎"ro" for
rounding mode is very clear for example.
Yes, that's questionable. What do others think?

My thinking was that people often specify the formatting ad-hoc, like
${n?string('0.00;;ro=hu')}, and then
${n?string('0.00;;roundig=half-up')} is perhaps too verbose. OTOH I
never liked these ad-hoc patterns in the templates, and that's one
reason why in 2.3.24 you can define a custom format, let's call it
"weight", as the alias of and other format string (like of "0.##"
etc.) in Configuration and/or Template and/or Environment, and then in
the template use ${n?***@weight}. If users will adopt this
approach, then '0.00;;roundig=half-up' is a clear winner. Otherwise
I'm not sure.
Post by b***@me.com
Also how do you decide if the currency symbol is before or after the
number?
The place of currency symbol is specified in the standard
DecimalFormat pattern with a "¤" (\u00A4) or "¤¤". In the extension
part we just allow overriding how it looks, not where it is.


P.S. I still post these mails on both dev lists, but who is still only
on freemarker-***@lists.sourceforge.net, please click on
dev-***@freemarker.incubator.apache.org!
--
Thanks,
Daniel Dekany
Post by b***@me.com
Cheers,
-- Denis.
  Original Message  
From: Daniel Dekany
Sent: Sunday, 13 September 2015 12:20
Reply To: Daniel Dekany
Subject: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings
Because not many people are here yet, it will be lazy vote. Is that
OK? 72 hours to go, unless there will be an active discussion of
course.
- Using half-up rounding mode instead of the Java default half-even
(https://sourceforge.net/p/freemarker/feature-requests/62/)
- Overriding the symbol used for NaN
(https://sourceforge.net/p/freemarker/feature-requests/67/)
- Using dot as decimal separator for certain numbers, instead of
the locale default (which was comma there) (but not the case of ?c)
(https://sourceforge.net/p/freemarker/feature-requests/117/)
I remember some other case (maybe it was just e-mail) where the user
has complained that in general he can't use all the features of
java.text.DecimalFormat as we only allow specifying the pattern
string.
The number format is specified with a string in FreeMarker. This is so
in the Configurable API, also in FTL (<#setting number_format="0.##">
and n?string("0.##")). So I wondered how to allow specifying the
parameters for DecimalFormat without making a mess, and found that we
can just extend the string parsed by DecimalFormat with a new section,
that would cause IllegalArgumentException if you pass it to
DecimalFormat as is, so it's backward compatible to add such a
section.
DecimalFormat accepts almost all kind of random string without
complaining. But it's string about ';'. DecmialFormat allows you to
specify two patterns, one for the positive, and another for the
negative numbers, separated by ';'. We could allow yet another ';' and
a further section, where the properties of the Decimal format can be
specified. So if someone wants '_' for grouping separator and half-up
rounding mode, then instead of ",##0.##", he could use ",##0.##;;
grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
number format) is empty. (This is backward compatible, as that's an
error for pure DecimalFormat.) In general, the 3rd section will be a
list of key=value pairs separated by whitespace and and optional
comma. If a value needs quoting, the quotation rules of DecimalFormat
patterns will be used (i.e, use apostrophe-quote, and double it for
- ro=u|d|c|f|hu|hd|he|un: RoundingMode
- mul: Multipier
- dec: DecimalSeparator
- grp: GroupingSeparator
- exp: ExponentSeparator
- min: MinusSign
- inf: Infinity
- nan: NaN
- prc: Percent
- prm: PerMill
- zero: ZeroDigit
- curc: Currency (ISO 4217 Code)
- curs: CurrencySymbol 2nd
- icurs: InternationalCurrencySymbol
- mdec: MonetaryDecimalSeparator
I will add this feature, if you agree.
------------------------------------------------------------------------------
Daniel Dekany
2015-09-16 09:14:01 UTC
Permalink
The 72 hours for lazy-voting is almost out, and I only had input from
one person, and none from PMC members. Anyone wants to add anything?

This VOTE will decide if there will be DecimalFormat option
assignments after the 2nd ";", as it was proposed (find it quoted
below). Except, how exactly the parameter names will look (like "rnd"
VS "rounding") will be figured out afterwards.

BTW, I have renamed "ro" to "rnd", as that's more in line with "grp"
and such. OTOH it reads as "RaNDom" for most of us, so it's just
another compromise.
Post by Daniel Dekany
Because not many people are here yet, it will be lazy vote. Is that
OK? 72 hours to go, unless there will be an active discussion of
course.
- Using half-up rounding mode instead of the Java default half-even
(https://sourceforge.net/p/freemarker/feature-requests/62/)
- Overriding the symbol used for NaN
(https://sourceforge.net/p/freemarker/feature-requests/67/)
- Using dot as decimal separator for certain numbers, instead of
the locale default (which was comma there) (but not the case of ?c)
(https://sourceforge.net/p/freemarker/feature-requests/117/)
I remember some other case (maybe it was just e-mail) where the user
has complained that in general he can't use all the features of
java.text.DecimalFormat as we only allow specifying the pattern
string.
The number format is specified with a string in FreeMarker. This is so
in the Configurable API, also in FTL (<#setting number_format="0.##">
and n?string("0.##")). So I wondered how to allow specifying the
parameters for DecimalFormat without making a mess, and found that we
can just extend the string parsed by DecimalFormat with a new section,
that would cause IllegalArgumentException if you pass it to
DecimalFormat as is, so it's backward compatible to add such a
section.
DecimalFormat accepts almost all kind of random string without
complaining. But it's string about ';'. DecmialFormat allows you to
specify two patterns, one for the positive, and another for the
negative numbers, separated by ';'. We could allow yet another ';' and
a further section, where the properties of the Decimal format can be
specified. So if someone wants '_' for grouping separator and half-up
rounding mode, then instead of ",##0.##", he could use ",##0.##;;
grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
number format) is empty. (This is backward compatible, as that's an
error for pure DecimalFormat.) In general, the 3rd section will be a
list of key=value pairs separated by whitespace and and optional
comma. If a value needs quoting, the quotation rules of DecimalFormat
patterns will be used (i.e, use apostrophe-quote, and double it for
- ro=u|d|c|f|hu|hd|he|un: RoundingMode
- mul: Multipier
- dec: DecimalSeparator
- grp: GroupingSeparator
- exp: ExponentSeparator
- min: MinusSign
- inf: Infinity
- nan: NaN
- prc: Percent
- prm: PerMill
- zero: ZeroDigit
- curc: Currency (ISO 4217 Code)
- curs: CurrencySymbol 2nd
- icurs: InternationalCurrencySymbol
- mdec: MonetaryDecimalSeparator
I will add this feature, if you agree.
--
Thanks,
Daniel Dekany
Evangelia Dendramis
2015-09-16 16:53:39 UTC
Permalink
Seems like an OK feature. +1.

I would like to note that as a front-end I've never needed that level of
flexibility for decimals since that logic has always been handled in the
backend. I've really only ever needed to manipulate the format for locales.
That's not to say the feature wouldn't be useful for a numbers-heavy app,
e.g. something finance or statistics related.
Post by Daniel Dekany
The 72 hours for lazy-voting is almost out, and I only had input from
one person, and none from PMC members. Anyone wants to add anything?
This VOTE will decide if there will be DecimalFormat option
assignments after the 2nd ";", as it was proposed (find it quoted
below). Except, how exactly the parameter names will look (like "rnd"
VS "rounding") will be figured out afterwards.
BTW, I have renamed "ro" to "rnd", as that's more in line with "grp"
and such. OTOH it reads as "RaNDom" for most of us, so it's just
another compromise.
Post by Daniel Dekany
Because not many people are here yet, it will be lazy vote. Is that
OK? 72 hours to go, unless there will be an active discussion of
course.
- Using half-up rounding mode instead of the Java default half-even
(https://sourceforge.net/p/freemarker/feature-requests/62/)
- Overriding the symbol used for NaN
(https://sourceforge.net/p/freemarker/feature-requests/67/)
- Using dot as decimal separator for certain numbers, instead of
the locale default (which was comma there) (but not the case of ?c)
(https://sourceforge.net/p/freemarker/feature-requests/117/)
I remember some other case (maybe it was just e-mail) where the user
has complained that in general he can't use all the features of
java.text.DecimalFormat as we only allow specifying the pattern
string.
The number format is specified with a string in FreeMarker. This is so
in the Configurable API, also in FTL (<#setting number_format="0.##">
and n?string("0.##")). So I wondered how to allow specifying the
parameters for DecimalFormat without making a mess, and found that we
can just extend the string parsed by DecimalFormat with a new section,
that would cause IllegalArgumentException if you pass it to
DecimalFormat as is, so it's backward compatible to add such a
section.
DecimalFormat accepts almost all kind of random string without
complaining. But it's string about ';'. DecmialFormat allows you to
specify two patterns, one for the positive, and another for the
negative numbers, separated by ';'. We could allow yet another ';' and
a further section, where the properties of the Decimal format can be
specified. So if someone wants '_' for grouping separator and half-up
rounding mode, then instead of ",##0.##", he could use ",##0.##;;
grp=_ ro=hu". The double ";;" is because the 2nd section (for negative
number format) is empty. (This is backward compatible, as that's an
error for pure DecimalFormat.) In general, the 3rd section will be a
list of key=value pairs separated by whitespace and and optional
comma. If a value needs quoting, the quotation rules of DecimalFormat
patterns will be used (i.e, use apostrophe-quote, and double it for
- ro=u|d|c|f|hu|hd|he|un: RoundingMode
- mul: Multipier
- dec: DecimalSeparator
- grp: GroupingSeparator
- exp: ExponentSeparator
- min: MinusSign
- inf: Infinity
- nan: NaN
- prc: Percent
- prm: PerMill
- zero: ZeroDigit
- curc: Currency (ISO 4217 Code)
- curs: CurrencySymbol 2nd
- icurs: InternationalCurrencySymbol
- mdec: MonetaryDecimalSeparator
I will add this feature, if you agree.
--
Thanks,
Daniel Dekany
------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
FreeMarker-devel mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Daniel Dekany
2015-09-16 17:18:09 UTC
Permalink
Post by Evangelia Dendramis
Seems like an OK feature. +1.
I would like to note that as a front-end I've never needed that
level of flexibility for decimals since that logic has always been
handled in the backend.
Yes, ideally, the number formats are set in the backend. But how did
you do that? People usually set the "number_format" setting in the
Configuration, but that has this limitation that you could only
specify the pattern part of DecimalFormat. Now you can use "extended
decimal format strings" there. (Plus, in 2.3.24, for a while, you can
also define logical number formats, like "price", "weight", etc., and
Post by Evangelia Dendramis
I've really only ever needed to manipulate the format for locales.
That's not to say the feature wouldn't be useful for a numbers-heavy
app, e.g. something finance or statistics related.
More flexible number and date formatting is a recurring request, so
it's clearly needed. The question is how to do it. Right now it's
extended DecimalFormat format strings, and the possibility of
registering custom formatters (so you need not use DecimalFormat or
SimpleDateFormat).
--
Thanks,
Daniel Dekany
Loading...