Saturday, August 18, 2007, 8:35:08 PM, Jonathan Revusky wrote:
> Daniel Dekany wrote:
>> Friday, August 17, 2007, 2:37:47 AM, Jonathan Revusky wrote:
>>> On 8/16/07, Daniel Dekany <ddekany@...> wrote:
>>>> Friday, August 17, 2007, 12:28:31 AM, Daniel Dekany wrote:
>>>>> And with similar logic, TemplateMethodModel-s can be implemented if
>>>>> #function and with TemplateMethodModelEx (/-: Well... this historical
>>>>> name is not very good to say the least in this case, but whatever). so
>>>>> if a functions should implement TemplateMethodModelEx, etc.
>>>> ??? %-S All right... I try it again, this time while I'm awaken:
>>>> And with similar logic, functions (or are those "methods"?) can be
>>>> implemented either with #function in FTL, or with
>>>> TemplateMethodModelEx in Java. (/-: These historical names don't
>>>> match, but what can we do...) So functions should implement
>>>> TemplateMethodModelEx (I'm not sure; do they already implement that?),
>>> No, they don't, though maybe they should. The thing is that functions
>>> are implemented in a slightly weird way, just as a macro, which
>>> returns a value, so they are just a macro, whose isFunction() method
>>> returns true.
>>> The implementation is actually a bit inelegant because functions
>>> really were implemented as a bit of an afterthought at a certain
>> Any hope these things will be changed?
> It's pretty likely that this will get fixed up in the 2.4 cycle, I would
> say. It's not so very important really, since so few users (if any)
> actually work directly with these things in freemarker.core.*.
Well, especially as the API is a quite a mess; now there is a chance
to improve on it a bit. (And, also, it's not clear at all what parts
of the API have BC guarantees, i.e. the packaging is wrong. Anyway,
you won't be able to fix the lack of API design without a totally new
API, which is then the possibly most backward incompatible, so never
> It's just that it is better to have a cleaner, more logical
> codebase, that's all.
May I note, it's better for developers/maintainers of FreeMarker as
well, like for you.
> In other matters, I am wondering whether we should continue support for
> the older syntax without the #, as in <if foo=="bar>...</if> which was
> the original FreeMarker syntax.
> By simply getting rid of it, I think the lexer part of the JavaCC
> grammar can be cleaned up a fair bit.
I think since 2.4 is non-BC we might as well get rid of it... together
with the 2.2 comparability mode. (I'm guess they become buggy since
> Also, in other matters, I introduced support for an abbreviated closing
> tag syntax, [/#] or </#>. Probably not to be encouraged for deeply
> nested constructs, but still, for short constructs it seems convenient.
For wise template authors it's a useful thing, but the less wise ones
will shot themselves on the foot sometimes. That said, for the
majority of humanity it will be bad. But you may prefer to give bigger
weight to the interest of the first group... Also at least it will be
consistent with </@>.
> I wouldn't emphasize it that much in the docs, just keep all the
> examples with the longer syntax, and just point out somewhere that the
> abbreviated syntax is also possible (though not always desirable.)
It will be shown where the directive syntax described, so it won't be
hidden, but I will not use it in the examples.