Re: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings

[br...@me.com]

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: dev@freemarker.incubator.apache.org
Reply To: Daniel Dekany
Cc: freemarker-devel@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


------------------------------------------------------------------------------
_______________________________________________
FreeMarker-devel mailing list
FreeMarker-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

Re: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings

[Daniel Dekany <dd...@freemail.hu>]

Wednesday, September 16, 2015, 6:53:39 PM, Evangelia Dendramis wrote:

> 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
then in the template write ${latitude?string.@price} and such.)

> 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

Re: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings

[Evangelia Dendramis <ev...@gmail.com>]

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.

On Wed, Sep 16, 2015 at 2:14 AM, Daniel Dekany <dd...@freemail.hu> wrote:

> 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.
>
> The original proposal:
>
> > 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
>
>
>
> ------------------------------------------------------------------------------
> 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
> FreeMarker-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

Re: [VOTE] Proposal: Extended decimal fomat strings

[Daniel Dekany <dd...@freemail.hu>]

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.

The original proposal:

> 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

Re: [Freemarker-devel] [VOTE] Proposal: Extended decimal fomat strings

[Daniel Dekany <dd...@freemail.hu>]

Sunday, September 13, 2015, 4:45:32 PM, bredelet@me.com wrote:

> 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.)

> 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.

> 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?string.@weight}. If users will adopt this
approach, then '0.00;;roundig=half-up' is a clear winner. Otherwise
I'm not sure.

> 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-devel@lists.sourceforge.net, please click on
dev-subscribe@freemarker.incubator.apache.org!

-- 
Thanks,
 Daniel Dekany


> Cheers,
>
> -- Denis.
>   Original Message  
> From: Daniel Dekany
> Sent: Sunday, 13 September 2015 12:20
> To: dev@freemarker.incubator.apache.org
> Reply To: Daniel Dekany
> Cc: freemarker-devel@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.
>