Re: Freemarker schedule related question

Thanks again for the answer. Null values issue is now clear to me.

Regarding BI - as you said - everyone will one day have list of BIs he would
like to have. BIs are very easy to use and very intuitive
for non-programmer people like web-devs. I know I risk with extending
Freemarker like this, but I think its worth the risk (hoping, that you'll
don't ban this by making class private). Your proposal of @BIs is
interesting, but I think it would be hard to explain to fellow web-devs why
this must by written like this:

${var?escape_url}
${escapedVar?@unescape_url}

I know, you stated, that this shoud be included in the base list. But it is
not, and if it would be added, there would surely be more other similar
cases, that someone will miss.

What about logging a warning, if custom BIs will override newly added system
BI when upgrading and properly document new BIs? It's up to everyone,
whether is takes the risk. Moreover, if custom BIs will have a priority over
system BIs (override) - it'll be a backward compatible. The concrete
implementations might only loose access to the newly added BIs of the same
name after upgrading. But old templates would work for them.

For example if you add new unescape_url BI, I would see the version
changelog or the warning in the application log, and consider whether your
BI doesn't do the same as my custom BI unescape_url. If it does, I could
safely remove my own BI, or make up delegation of extension relation between
your new BI and my own old. What do you think?

Jan

2010/3/25 Daniel Dekany <[email protected]>

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



-- 
--------------------------------------------------------------
Ing. Jan Novotný
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
http://blog.novoj.net
Myšlenky dne otce Fura
--------------------------------------------------------------

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