Re: Freemarker schedule related question

Thursday, March 25, 2010, 12:38:38 PM, Ing. Jan Novotný wrote:

> Thank you for the exhausting reply. I hadn't anticipated, that
> there are so many issues connected with that release (as it always
> is like that with bigger projects). Now I have much cleaner view on the matter.
>
> You mentioned ugly .null variable - is it some custom extension or
> what is that.

It's a special variable (http://freemarker.org/docs/ref_specvar.html),
but it seems it will not exist, so whatever.

> I searched through global variables documentation and
> there is nothing about it
> (http://freemarker.sourceforge.net/docs/ref_specvar.html). I do null check in two ways:
>
> <#if variable??/>

That will work even with null support.

> or when I need an assign:
>
> <#assign newVar=obj.apiCall()!'<Undefined>'/>
> <#if newVar != 'Undefined'> ...

That too. Only with null-support it will be less messy:

  <#assign newVar=obj.apiCall()>
  <#if !newVar?is_null> ...

> But the second way is so ugly that I very much look forward to the
> null keyword. Is there is any better way of handling nulls?

Not yet, not really...

> The second thing I wanted to ask. I must admin, that I've hooked
> into an unpublic builtin API - to add my new builtins. The built-in
> paradigm is so handy, that I couldn't resist not to use it for
> adding new build-ins for our web developers. Do you  plan to open
> this mechanism as a part of open Java API? My current hook is as follows:
>
> package freemarker.core;
>
> /**
>  * Custom Freemarker built ins extension - cannot do it better because framework secures access
>  * to built-ins not allowing external libraries directly add their own.
>  *
>  * @author Jan Novotný, FG Forrest a.s. (c) 2007
>  * @version $Id: BuiltInExtension.java,v 1.4 2010/03/05 08:23:39 u_novoj Exp $
>  */
> public class BuiltInExtension {
>
>  public static void init() {
>   BuiltIn.builtins.put("unescape_url", new UnescapeUrl());
>   BuiltIn.builtins.put("json", new ObjectToJson());

(Hm... "json" rather should be a real BI. So should unescape_url be
maybe. And untag. Etc. Well, I have many should-be-added BI-s on my
list, so one day...)

>   BuiltIn.builtins.put("remove_diacritics", new RemoveDiacritics());
>   ... more ...
>  }
>
> }
>
> What's you opinion on that?

The whole point of BI-s is that we can add new ones without breaking
backward-compatibility. But if users can add BI-s... that point is
lost. Either you can't just blindly upgrade from 2.x.y to 2.x.y+1
anymore, or we can't add new BI-s anymore without doing a non-BC
release with increased 2nd version number. So, anyway, what's so
tempting about BI-s? I guess it's the postfix syntax and lack of
parentheses when there are no parameters. For that reason I proposed
we just allow calling #function-s/methods with a similar syntax: "?@"
instead of "?", like ${myVar?@json}. (The "@" tries to play on
people's association of @ with user-defined stuff, like <@myMacro />.)

> Thanks again for your previous prompt answer,
> Jan
>
> 2010/3/25 Daniel Dekany <[email protected]>
> Thursday, March 25, 2010, 7:47:20 AM, Ing. Jan Novotný wrote:
>
>> Hello,
>>
>>    is there any roadmap that would state where there could be 2.4
>> stable out? I'd like to get advantage of new null handling behaviour. Thanks for the reply.
>
> Ugh... all right, let's see, at least some of devels will see the
> picture at least.
>
> First, I have to clarify something regarding the version numbers...
> Although you still see 2.4-pre1 on our page (again, guys, can I remove
> that thing?), if that branch will be released ever at all, that will
> be most probably 3.0. Now there is a plan to release a 2.4, but that's
> basically 2.3 changed so that it complies with the GWE (for Google Web
> Engine) (GWE doesn't comply with J2SE 1.3 or later, the target
> platform of FreeMarker 2.3), which required non-backward compatible
> changes (even if only minor ones) and hence it can't be called
> 2.3.<something> according to our version number policy.
>
> As of null-handling... Attila hinted earlier that he could back-port
> that into 2.4 (which is 2.3 GWE). And technically he could for sure...
> however, as it turns out that it can't be done without *substantially*
> breaking backward compatibility (at least as far as I see). Surely 2.4
> can be non-compatible with 2.3 according the version policy, however,
> since many will only switch to 2.4 to run their *existing*
> applications on GWE, these really should be minor ones this time. So
> null-handling can only go into, like, 2.5... UNLESS it becomes a
> Configuration-level setting in 2.4: "null_aware", false by default. If
> Attila thinks that that's not too big deal to implement, that would be
> great. (And BTW if null_aware=true, then null could be a keyword; no
> need for that ugly .null anywhere.) (Actually, this null_aware thing
> would be desirable for one another reason... When we want to introduce
> something non-BC and profound in version x.y.0, it should be already
> in the wild with version x.(y-1).z, so people can start experimenting
> with it and "migrate" long before it becomes active be default.)
>
> Now, the whens... That's horrendously unpredictable here. But I
> believe 2.4.0 (final) will be out within a few months. And if Attila
> will agree with the null_aware setting thing, you will have
> null-support that early. Or actually earlier... because in that case a
> practically stable 2.4 that already has this optional null-support
> will appear much earlier in the SVN for sure. AFAIR Attila already has
> 2.3 GWE + null-support on his computer, only null-support isn't
> optional yet, and that's a problem for 2.4. But I don't know yet what
> he will think about making that a config. option.
>
>> Regards,
>> Jan
>
> --
> 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
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>
>
>

-- 
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
_______________________________________________
FreeMarker-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-user