Re: Quick note about future number handling

Daniel Dekany wrote:
> Saturday, March 20, 2010, 2:33:18 AM, Brian Pontarelli wrote:
>
>   
>> I've run into issues over the past 4 years due to the default
>> number handling in templates.  The problem is regarding the
>> difference between ${n} and ${n?c} and it has consistently been an issue.
>>
>> The problem is that testing generally doesn't find issues until
>> database and other IDs exceed 1000 and FreeMarker begins to insert commas such as:
>>
>>         1,020
>>
>> This generally occurs when the template is creating URLs or form
>> fields that should contain integer values such as IDs. When the
>> value is sent to the server via HTTP, it contains a comma and that
>> breaks the Integer.parseInt() methods parsing.
>>
>> I would suggest a change with the first backwards-incompatible
>> release that changes the handling. The default handling should be to
>> print out the number with no formatting in the same way that Java
>> does. If you want to format it, you should need to do so explicitly,
>> in the same way that java does. Here's the change for n = 1000:
>>
>>         ${n} = 1000
>>         ${n?string("#,###.##")} = 1,000
>>     
>
> Or rather ${n?h} (h for Human audience) or something... Anyway, I
> agree that this is a big problem. In any new language I surely would
> use a ?c-ish formatting as the default. Doing such a change in FTL,
> however, would be a quite brutal change, as there is not even
> semi-automatic way to revisit existing templates for this. But
> certainly it needs to be done regardless.
>   
Hi there.

If you wanted to maintain backward compatibility, perhaps you could 
leave the default as is and provide a method on the 
Template/Configuration instance for overriding the default formatting.  
Could also do same with a new computer readable default, allowing 
existing users to override the default back to the old human readable 
default (which I've also found to be a total PITA :) ).

In fact.... would this be nice to have for all types... including Dates 
etc e.g.

    configuration.setDefaultFormatting(Number.class, "c");
    configuration.setDefaultFormatting(Date.class, "string('yyyy-MM-dd')");
    // etc...
      

Actually ... just looked at the API and it appears to already be there 
on the Configuration class i.e. setNumberFormat(String) and 
setDateFormat(String) :)  Why did I never see that before :)

Regards,

T.
>   
>> I know there are a number of ideas floating about for an
>> incompatible release (possibly 3.0) and I would like to toss this
>> one in there.
>>
>> -bp
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> FreeMarker-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>
>>     
>
>   

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev