Re: Freemarker schedule related question

Thursday, March 25, 2010, 3:29:05 PM, Ing. Jan Novotný wrote:

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

Yes, this is an issue. Even independently of FM, I could never figure
out a solution for this that is not painful somewhere. For example,
you can say that custom BI-s override built-in ones, so adding new BI
won't be non-BC. That would many users happy, at least first... But
you can imagine where it leads to. Because, what if you have
overridden a core BI, and then you get a template from somewhere that
tries to use the core BI... Also, till now it was obvious that
whenever you see ?foo, you can look it up in the manual, while when
you see foo(), you have to ask your colleagues. Etc. Now, actually in
my new template language designs (vapor-ware op far) I still choose
something that is very similar to this path... but there are several
features there that make the situation more manageable, most
importantly, declarative defining of custom template languages (so an
eclipse plugin can automatically support your language), and this of
course means that the template engine assumes in its very guts that
there are multiple languages. I don't think this will make into FM in
the foreseeable future, /-: (there are HR issues for starters) but
when it does, we can just deprecate @. Standard way of adding
docstrings would also become more and more important as the "BI-hell"
escalates. Not that the method-hell is different...

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

Of course, the list of BI-s never can be complete. Many formatting
tricks are application-specific.

> What about logging a warning, if custom BIs will override newly
> added system BI when upgrading and properly document new BIs?

Logging warnings is a good way of making the logs bigger and rotate
more often... because, now frankly, how many of use monitor logs
before facing an actual problem that we have to figure out?

> It's up to everyone, whether is takes the risk.

This is like the thing with logging... Developers like to push thing
both on that and this. Neither works out well in practice. If you
users tend to do a mess, on their own risk, using your product in
practice will be a mess. Anyway, I'm just saying that "users take
risk" is not a good reasoning in itself.

> Moreover, if custom BIs will have a priority over system BIs
> (override) - it'll be a backward compatible.

Yip...

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

See earlier. Maybe? With FM I lean to ?@, but...

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

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