2017-01-08 15:00 GMT+01:00 Daniel Dekany <ddek...@freemail.hu>:
> 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).
>
All good ideas. I got the plusXXX from the Joda-Time API guys e.g.
http://www.joda.org/joda-time/apidocs/org/joda/time/
DateTime.html#plusDays-int-
I am fine with ?add_day(1) too...and week,month, year :)
> [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
> `?`).
>
I guess you are referring to http://freemarker.org/docs/
dgui_misc_namespace.html when you say "already". Yes we use auto-imports
internally for some helper-macros in our templates. But they are not
exposed for users. We could, but at the moment we use TemplateMethodModels
for any additional user-facing functionality.
> > 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.
>
Hmm ok I see.
I guess I am fine with ${x?my:bar} so we could provider all our own custom
built-ins under this "my" prefix (or "sy" as we already do with our
auto-import macros <@sy.foo "bar" />)
>
> [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.)
>
> Ah ok I see what you mean:
The '.' tells you want to call something on the object,
exp.#trim would call a FM built-in while
exp.trim would call the trim() method on the underlying object in the data
model.
Maybe I am the wrong person. I got used to the '?' operator.
I was fine with the logic in my head:
*Things calling stuff on the object directly:*
'.' calls functions on the underlying object
? calls a FM built-in (which can be chained)
*Method-like things*
<#xxx> is a directive (if, else, list, all that stuff)
<@foo> are macros (I always see them as functions...something which takes
parameters and does something. )
${function(params)> are function calls defined by <#function . They look
the same as TemplateMethodModels
My gut-feeling tells me that every extra thing / character which makes
something look more verbose can be bad. But I also understand the technical
side, that you need to distinguish between FM-core functions and the other
functions.
There are some interesting articles on language verbosity:
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-
expressiveness/
http://www.michael-snell.com/2015/03/on-verbosity-in-
programming-languages.html
Maybe it would be a good idea to write down the different notation-ideas on
a single page somewhere and compare it side-by-side and ask more people
about opinions.
I think that syntax is an important topic, and the more "right" or
"accepted" you can get it, the better. I am pretty satisfied with the
current syntax, so you should carefully discuss the pros and cons of a new
syntax.
Thanks
Christoph
> --
> Thanks,
> Daniel Dekany
>
>
--
Christoph Rüger, Geschäftsführer
Synesty <https://synesty.com/> - Automatisierung, Schnittstellen, Datenfeeds
Tel.: +49 3641/559649 <+49%203641%20559649>
Xing: https://www.xing.com/profile/Christoph_Rueger2
LinkedIn: http://www.linkedin.com/pub/christoph-rueger/a/685/198
--
Synesty GmbH
Moritz-von-Rohr-Str. 1a
07745 Jena
Tel.: +49 3641 559649
Fax.: +49 3641 5596499
Internet: http://synesty.com
Geschäftsführer: Christoph Rüger
Unternehmenssitz: Jena
Handelsregister B beim Amtsgericht: Jena
Handelsregister-Nummer: HRB 508766
Ust-IdNr.: DE287564982
