Re: Quick note about future number handling

Saturday, March 20, 2010, 5:30:40 PM, Brian Pontarelli wrote:

>> 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 :)
>
> The main issue will be when templates are from a 3rd party.
> JCatapult allows you to ship the templates insides JAR files and
> then it can dynamically look them up. This makes packaging reusable
> features easy. However, those templates might break if the configuration is changed.
>
> I vote for changing the default or providing a template level
> default change. My issue with template level changes is that it is
> more overhead and boilerplate for every template.

I think that the only way however: <#ftl default_audience="computer">.
That's 100% backward-compatible. If you are going to change the global
default in the Configuration object... it's your "responsibility".

Now, the way FM could help a bit more of you could specify the default
based on the template name. Like, you say that "/jcataoult" uses a
human audience, others do computer audience. But this, well... will
also cause a lot of confusion. But I can't imagine anything better.

Of course, technically, we can change the default at some point in the
*far* future. When 2.5 or 3.0 comes, we will look around, what did
people do with the audience defaults, so we can form a more realistic
standpoint regarding if this change should be done.

> I'd rather just see the default changed in 3.0.
>
> Perhaps someone should collect a list of the backwards incompatible
> changes and start planning for that release? These would be the items on my list:
>
>         - Type formatting

What's tjat...

>         - Map handling

If this is about writable maps, then I belive that's
backward-compatible.

>         - Direct wrappers as default (this was a pretty long thread a few months ago)

Direct wrappers... you mean no more viisble object-wrappers? /-: No
way, that's a halmark of FM. Even if a bad one for most... it's still
a feature why many projects have chosen FM over JSP (or Velocity). We
should provide a better object wrapper by default however. But that's
again the same category as the default-audience changes: release it as
an option, push it a bit in the Manual, see if people want to adopt
it, see if it has unforeseen problems... and then we can decide if
it's time to set that as the default in 2.5 (or 3.0).

> I think I've brought up a couple others, just can't remember them right now.

The Version History in the once-was-2.4 (now 3.0) Manual is a good
source on that.

> -bp

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Download Intel&#174; 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