Re: Quick note about future number handling

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

Yeah, I wouldn't find that features useful in most places, and just more overhead and boilerplate. It would be equally frustrating to forget that declaration and end up with the same situation as leaving out ?c


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

I also wouldn't use that features as it would be more "magic" to explain to my users.


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

This is my vote. For now, I'll just use ?c


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

What we've been talking about ;)


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

Definitely. And using key types besides Strings without using (key). I'd prefer direct access to all of Java is possible. This goes along with the Wrapper fixes. By really reworking the wrappers I think things could be cleaned up a lot.


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

No on removing them. No on invisible object-wrappers. Yes on better wrapping and support for Java access, object transfers, etc. I'd prefer all of these things to be defaults with the first non-backwards compat release.

I think we agree on the method for doing these things. Make the changes to support the new semantics and reveal them as template or configuration level controls. Then eventually switch the defaults.

-bp

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

_______________________________________________
FreeMarker-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-user