Sunday, January 8, 2017, 1:10:11 AM, Christoph Rüger wrote:
[snip]
> ok.
> I like the chainability of Joda-Time API e.g.
> ${mydate?plusDay(1)?string("yyyy-MM-dd")}
> ${mydate?date_trunc("month")}
Or, since there's ?plus_day(n) (instead of ?date_plus("day", n)), it
should be ?date_trunc_month(1). Or the other way around (both should
have a parameter like "day" and "month"), but typos in that string
aren't spotted until runtime, so maybe the first approach is better.
Also instead of ?plus_day, ?add_day is perhaps marginally better,
because ?plus_day(-1) look a bit stranger than ?add_day(-1).
[snip]
>>> *my wishes would be (for the moment):*
>>> - be able to create custom built-ins (like TemplateMethodModels but with
>>> the ?mybuiltin syntax). This would allow us to build some custom functions
>>> with the same syntax and it could be used like a fluent-interface
>>> ?funcA?funcB?funcC
>>
>> That's a frequently required thing, but it raises some tricky
>> problems. The whole point of built-ins was that since the `?` syntax
>> is reserved for the template language, we can add new built-ins
>> without breaking backward compatibility. And another advantage of them
>> is that you can look them up in the FreeMarker Manual, because nobody
>> can add/remove them.
>>
>> For FM 3, I'm thinking about introducing #import namespace prefixes
>> that use `:` instead of `.`. So then, you would write `<#my:foo />`
>> instead of `<@my.foo />`. Yes, that doesn't help so far, but it opens
>> the possibility of writing x?my:bar, while with `.` it couldn't work
>> (`x?my.bar`, which just means `(x?my).bar`). So this allows you to use
>> the `arg?f` syntax instead of `f(arg)`), but only if you are using a
>> namespace prefix (`my`), so that it's clearly separated from the core
>> callables.
>>
>> However, some, especially in projects like yours, doesn't want to
>> burden the user with such a prefix (`my:`) either. You just want to
>> write `x?bar`. So that's also a valid use case, if you provide a
>> complete documentation for your users instead them trying to look up
>> things in the FreeMarker Manual. Because the problem with is not
>> technical; it's the seer chaos this can start. Imagine if every second
>> project starts to define his own FTL dialect, because now they can do
>> it easily, without forking... My thought on this is that you should be
>> allowed to define a custom FTL dialect, but then you aren't allowed to
>> call it FTL or a FreeMarker Template. It would be Synesty Template
>> Language (*.stl) or whatever. So then, you have your own specialized
>> language, no silly prefixes, just what your users need (also no core
>> FreeMarker functionality that you don't want to expose to your users),
>> yet you didn't have to fork, and you benefit from the new FreeMarker
>> releases. So I want the FM 3 architecture to be able to handle this
>> task, but there are some non-technical issues with it; we might open
>> some a Pandora's box be allowing this.
>
> This sounds pretty interesting and opens up new possibilities. I
> can see this might be useful for us.
> If we could define our own namespace globally also one idea could
> be to define some kind of default namespace like you can do with FM's
> XML-namespace handling:
> <#ftl ns_prefixes={"D":"http://example.com/ebook"}>
>
> What you say about the chaos makes total sense, but I still like
> the idea of adding stuff on top of the FM-core-functionality.
I also want to go for it, but it remains to be seen what others will
think about it. I guess as far as we communicate clearly when using a
a custom dialect is appropriate, and as far as we try to enforce
technically that people don't use ftl file extension, and show clearly
in error messages that you aren't using FTL but STL or whatever (in
case where it can have importance), it will be a much better
compromise than what we have in FM 2.
> Maybe it could be configurable somehow e.g. in pseudo-code :
>
> templateDialectMode=fm-core (as it is today...only FM-core, nothing else)
> templateDialectMode=extend (FM-core + own functions using a prefix.)
If you are using a prefix, then it's an auto-import (which you can do
already, though not with `:` and so you can call those functions with
`?`).
> templateDialectMode=onlyOwnNamespaces (no FM-core, only own namespaces)
>
> The latter would be great if you want to provide an (sandboxed)
> environment with kind of a custom DSL (domain specific language) which should
> be very limited.
>
> I think the general rule should be: FM-core functions are not
> customizable, but you should be able to add on top of it.
That won't work, because then adding a new FM-core function will break
backward compatibility.
[snip]
> I guess your namespace/dialect thing is THE feature and could help
> a lot so that we are able to do things the way we want and still
> benefiting from the base and syntax FM provides.
> I see FM and especially the syntax as a very cool - let's call it
> framework. Once we have tought our customers how the general syntax
> works (e.g. ${var1} foo ${var2} is easy to get and also
> ${mystring?lower_case} is easy to understand
[snip]
Or is it? I was wondering for a while whether instead of
`exp?trim?upperCase` the more verbose `exp.#trim.#upperCase` would be
easier to grasp. Yes, it's uglier if your eyes are used to FTL. But if
not (and let's face it, that's the majority), as you probably already
know `.`, it's easy to understand that FTL adds some member its own,
and the names of those start with `#`. No additional operator, no
doubts about the precedence of it. (It's like extension methods in
some other languages, only it's clear at glance what's an extension
method.)
--
Thanks,
Daniel Dekany
