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).
>
