Tuesday, December 1, 2015, 6:30:48 PM, Lee wrote:
> FreeMarker 3 could be beneficial. What does this item mean?
> "Separately pluggable expression language and "outer" language"
In a (typical) template language, you have static text sections (i.e.
raw output) on the top level, and then there's some template language
sections embedded into that (interpolations and FTL tags in our case)
with some delimiters (`${...}`, `<#name ...>, etc. in our case). So
those are basically the things defined by the "outer language".
Between these delimiters you are using some "expression language".
Why replaceable outer language matters? First of all, the outer
language sometimes clashes with the static text (like you have to
write templates for a scripts or JSP that already uses ${...} a lot,
which hence you had to escape out). Secondly, during the years I have
found that the look-and-feel of the outer language is something that
people tend to be sentimental about. Like many reject FreeMarker
because they find `<#name ...>` scary/ugly, while they have no problem
with `#name(...)...#end` (Velocitish syntax), or `#name(...) {...}`
(Webmacroish syntax), even if it means the same.
Why replaceable expression language matters? I'm not so happy about
that, but anyway, if you are working with a certainly language, and
then you switch to editing a template, for many it's annoying to
switch their brain to FTL expression language syntax. Then there's the
approach where you just use another language to calculate expression
values... something that will be interesting to explore, but it's a
quite tricky problem. Like, let's say you use JavaScript expressions
via Nashorn. What corresponds to "foo?someBuiltIn", for example? If
FTL will have `:` as in XML, what will correspond to that? Etc.
Anyway, for FTL3, I think the point is just having these two languages
separated. So later it will be possible to play around with replacing
at least the outer language.
--
Thanks,
Daniel Dekany
> On Sun, Nov 29, 2015 at 3:07 AM, Daniel Dekany <[email protected]> wrote:
> Sunday, November 29, 2015, 11:28:31 AM, Daniel Dekany wrote:
>
> [snip]
>> - Dropping all the not-recommended-anymore and deprecated features,
>> obviously. There's a lot, trust me...
>> - Rename things that has confusing name, or are in the wrong package
>> - Unify the concept of macros and (user-defined-)directives. Same with
>> functions and methods. These are separate concepts yet similar in
>> the current code base.
>> - Parser/syntax:
>> - FTL3:
>> - Null-aware, has a behavior that's more like Groovy's
>> - Hash "map" type instead of "hash" (i.e., no string-keys-only BS
>> anymore)
>> - Better whitespace handling
>> - Has simpler, more regular syntax.
>> - Designed to make user-defined dialects possible
>> - Some minor changes in expression syntax... doesn't mater for now.
>> - Separately pluggable expression language and "outer" language
>> - Made with IDE and template-introspection support in mind
>> - Template loading/caching:
>> - A better version of the TemplateLoader mechanism. The current one
>> has problems with being effective with DB for example.
>> - In general, template loading/caching need to be more pluggable.
>> Right now it's often hard to reuse your framework's existing
>> caching facility for example.
>>
>> So that's a FM 3.0, plus whatever I have forgotten about. That's a lot
>> of work you see there, but it's rewarding.
>
> And one that I have forgotten:
>
> - Modularize FM. There should be a bare-bone engine Maven module, and
> then a separate Servlet Maven module, a JSP Maven module, Jython
> module (if there's still interest in that), etc. (Maybe even XML
> support should be separate.) This will also help to migrate the
> project build to to Maven. Another aspect of this is that 3.0 can be
> released without all the other modules to be cleaned up and ready
> (especially Serlvet/JSP will be a substantial work).
>
> --
> Thanks,
> Daniel Dekany
