Re: Freemarker schedule related question

Yes, I feel that you are right in every single point. I must admit, that my
endeavour was driven by a need of legalization things I have already done in
a pirate kind of way. At least I cannot say, that I didn't try ;-). Thanks
for explanation of your point of view.

Have a nice weekend,
Jan

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

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



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