Quick note about future number handling

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

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