You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Daniel Dekany <dd...@freemail.hu> on 2015/11/29 11:28:31 UTC
Is it time to start a FreeMarker 3 branch?
I was wondering if for how long should we add major features to the
backward compatibility bound 2.3+ line (2.3.x, and 2.4.x). With
FreeMarker 3 I mean shamelessly dropping BC (while remaining
recognizable), move the existing code base to a different package
(like org.apache.freemarker3 or org.freemarker.v3) so that it can be
used in parallel with FreeMarker 2, and cleaning it up from all the
historical mistakes (this includes syntactical adjustments,
introducing FTL3). I'm thinking in refactoring/cleanup in smaller
steps, and rewriting as few parts as possible (like the parser).
Doing this is possibly a turndown for 2.x user, but after 11 years
since 2.3.0, and nearly 0 contribution from the companies relying on
FM, doing this is perhaps not that outrageous. And it's not like 2.3
won't get fixes or even smaller backported features. Anyway, why do I
think it should be done:
* Development costs:
It's possible to play a round with the incompatibleImprovements
setting in 2.x almost indefinitely, but the more fundamental legacy
issues you address, the more expensive it is in terms of developer
time to make that fix optional (i.e., something you can turn on via
incompatibleImprovements), and developer time is scarce. I'm afraid
that without cutting these expenses, most of the deeper fixes will
just never happen or happen too late, also new/innovative features
will delay too much.
* Complexity pushed on the user:
The sometimes confusing legacy public API and the growing amount of
legacy/redundant features, which are confusing for the user, you
can't fix with incompatibleImprovements. So while users who are
dependant on 2.x are possibly better of with messing with this
additional complexity (on the short term at least), all the new
users are negatively affected.
* Attractiveness for new developers:
Dragging all the legacy with us means substantial additional code
complexity and code ugliness. Thus contributions are harder to make,
and most importantly, long term developers are hard to catch.
(Some may ask, what about 2.4? I have kept putting things into 2.3
that were meant for 2.4... like Java 5. I just don't know when and if
anyone will find the energy to release 2.4, for the few remaining
things must remain 2.4-exclusive.)
You may ask what I want to change:
- 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.
--
Thanks,
Daniel Dekany
Re: Is it time to start a FreeMarker 3 branch?
Posted by Daniel Dekany <dd...@freemail.hu>.
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 <dd...@freemail.hu> 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
Re: Is it time to start a FreeMarker 3 branch?
Posted by Lee <ev...@gmail.com>.
FreeMarker 3 could be beneficial. What does this item mean? "Separately
pluggable expression language and "outer" language"
On Sun, Nov 29, 2015 at 3:07 AM, Daniel Dekany <dd...@freemail.hu> 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
>
>
Re: Is it time to start a FreeMarker 3 branch?
Posted by Daniel Dekany <dd...@freemail.hu>.
Even more additions to this:
- Of course, first of all we have to get 2.3.24 to be released (RC1
first). There's quite a few important new features in it. It would
be good if some of you try to find the problems with the new API-s
and features. Not just bugs, but design issues. Those can't be fixed
later.
- I will create a list of new features which I think must be
implemented for FTL3 to be releasable. And then, I will pick those
that can be put into 2.3 without too much overhead, and implement
them in 2.3.
- Another heavy change that I consider in FTL3 is making variable
"creation" more static, and more familiar looking. People often want
to be able to tell programmatically what model variables are used in
a template, but with ad-hoc created variables it's not possible to
tell reliably. Plus, I think #assign/#local/#global (and esp.
#assign) is ugly. I think, #var and #set is much cuter, where #set
without corresponding #var is a "compilation" time error (hence can
also be marked by editor plugins). (You might know the annoyance
when you make a typo in the assigned variable name, but you don't
get an error, not even on runtime, and it silently creates a new
variable). I would also make #var scoped by the closest enclosing
block (like `let` in ES6). So #var naturally takes the role of
#local too. What about #global, etc.? I think we will need `:` as in
XML anyway, so it can be <#set global:x = 123> and ${global:x} or
like. So what I'm shooting for is that if you have a `${x}` then you
can tell (syntax-highlight) right in the editor if it's a data-model
variable or a template-created variable (#var or macro/function
argument).
--
Thanks,
Daniel Dekany
Sunday, November 29, 2015, 12:07:15 PM, Daniel Dekany 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).
>
Re: Is it time to start a FreeMarker 3 branch?
Posted by Daniel Dekany <dd...@freemail.hu>.
Actually, yes, that's even better. (If there ever will be a FM 4, it
can still use org.apache.freemarker4 after all.)
Tuesday, December 1, 2015, 11:05:03 PM, Jacques Le Roux wrote:
> To keep things simple why not org.apache.freemarker?
>
> Jacques
>
> Le 01/12/2015 18:58, Woonsan Ko a écrit :
>> +1 on all you described for FTL3.
>>
>> Just a side note, I like 'org.apache.freemarker3' better as new
>> package name. I saw a similar pattern in Apache Commons. e.g,
>> org.apache.commons.lang3.
>>
>> Regards,
>>
>> Woonsan
>>
>>
>> On Sun, Nov 29, 2015 at 6:07 AM, Daniel Dekany <dd...@freemail.hu> 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
>>>
>
--
Thanks,
Daniel Dekany
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Re: Is it time to start a FreeMarker 3 branch?
Posted by Jacques Le Roux <ja...@les7arts.com>.
To keep things simple why not org.apache.freemarker?
Jacques
Le 01/12/2015 18:58, Woonsan Ko a écrit :
> +1 on all you described for FTL3.
>
> Just a side note, I like 'org.apache.freemarker3' better as new
> package name. I saw a similar pattern in Apache Commons. e.g,
> org.apache.commons.lang3.
>
> Regards,
>
> Woonsan
>
>
> On Sun, Nov 29, 2015 at 6:07 AM, Daniel Dekany <dd...@freemail.hu> 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
>>
Re: Is it time to start a FreeMarker 3 branch?
Posted by Daniel Dekany <dd...@freemail.hu>.
As far as I'm concerned, as far as we can be inside ASF, that's what
it will be.
--
Thanks,
Daniel Dekany
Tuesday, December 1, 2015, 6:58:07 PM, Woonsan Ko wrote:
> +1 on all you described for FTL3.
>
> Just a side note, I like 'org.apache.freemarker3' better as new
> package name. I saw a similar pattern in Apache Commons. e.g,
> org.apache.commons.lang3.
>
> Regards,
>
> Woonsan
>
>
> On Sun, Nov 29, 2015 at 6:07 AM, Daniel Dekany <dd...@freemail.hu> 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
>>
>
Re: Is it time to start a FreeMarker 3 branch?
Posted by Woonsan Ko <wo...@apache.org>.
+1 on all you described for FTL3.
Just a side note, I like 'org.apache.freemarker3' better as new
package name. I saw a similar pattern in Apache Commons. e.g,
org.apache.commons.lang3.
Regards,
Woonsan
On Sun, Nov 29, 2015 at 6:07 AM, Daniel Dekany <dd...@freemail.hu> 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
>
Re: Is it time to start a FreeMarker 3 branch?
Posted by Daniel Dekany <dd...@freemail.hu>.
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