Sunday, September 13, 2015, 4:45:32 PM, [email protected] 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 [email protected], please click on
[email protected]!

-- 
Thanks,
 Daniel Dekany


> Cheers,
>
> -- Denis.
>   Original Message  
> From: Daniel Dekany
> Sent: Sunday, 13 September 2015 12:20
> To: [email protected]
> Reply To: Daniel Dekany
> Cc: [email protected]
> 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.
>

Reply via email to