Relevant extract from the Incubator report to the Board

[Jacopo Cappellato]

Hi all,

I would like to highlight the following paragraph from the draft of this
month's Incubator report:

==
The following appear to be close from maturity model:

  - Airflow
  - BatchEE
  - FreeMarker
  - Metron
==

We are getting closer to a successful graduation so let's keep going in the
right direction!

Jacopo

Re: FreeMarker Project Maturity Model Assessment

[Sergio Fernández]

In case it helps, in Beam (recently graduated) did a quite good work on
that aspect: https://beam.apache.org/contribute/maturity-model/

The place (svn/git/confluence/moinmoin/etc) does not matter at all; the
content it the important thing.

On Sat, Jan 7, 2017 at 11:04 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> The Confluence version at the ASF works well now. It's a reliable WYSIWG
> version.
>
> One of the big advantages of Confluence is it allows finely grained
> permissions. This is not only useful with spam.
>
> Another advantage is it has, even at the ASF, a lot of available plugins
>
> This said it can be sometimes a bit slow, and creating long complicated
> page can turn to a be nightmare especially if you put a lot of images. At
> least now you never lose anything, it has a very good automated versionning
> system...
>
> Jacques
>
> PS: I don't think anybody is a Confluence huge fan ;)
> https://lists.apache.org/thread.html/1adaf03b52c34de6a3502a9
> bab2f8c27548071d2105aeac41f11ccf4@1432806673@%3Cuser.ofbiz.apache.org%3E
>
>
>
> Le 07/01/2017 à 20:36, Daniel Dekany a écrit :
>
>> Does Confluence work well for developer topics though? Because I guess
>> we will want to use it for FM3. I had to use it on workplace, a
>> relatively old version, and it was a nightmare because it gets
>> confused by the odd stuff we programmers write... and yes, there are
>> some escaping rules and all, but over all it wasn't practical to use,
>> plus it was buggy... though yet again maybe nowadays it's better.
>>
>>
>> Saturday, January 7, 2017, 7:17:07 PM, Jacques Le Roux wrote:
>>
>> I'd prefer Confluence as we have experience with it in the OFBiz team
>>>
>>> My 2cts
>>>
>>> Jacques
>>>
>>>
>>> Le 07/01/2017 à 18:49, Jacopo Cappellato a écrit :
>>>
 On Sat, Jan 7, 2017 at 6:47 PM, Daniel Dekany 
 wrote:

 We have never requested a wiki from infra... so I as far as know we
> don't have it yet.
>
 Should we request one? It can be useful to work together on a shared
 document like in this case. Suggestions/proposals/preferences?

 Jacopo


>>>
>


-- 
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernan...@redlink.co
w: http://redlink.co

Re: Thoughts on using FM with Transformy (Was: Using Social Media to Help Promote Freemarker)

[Christoph Rüger]

2017-01-08 15:00 GMT+01:00 Daniel Dekany :

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