Monday, February 12, 2018, 12:52:26 AM, jpr...@seznam.cz wrote:
> It seems reasonable. As you suggested, it also seems a little advanced in
> style for most cases.
> It's very flexible, a bit verbose for common use, a bit of a learning curve
> for template author.
> I would prefer a shorter name, like ".get_template". Isn't it up to the
> template author to decide if the template is optional and what to do if it's
> not found?
If it's not optional, then using this new method is (almost) useless,
as you can just use #include or #import. Also note that we have a
problem with handling a returned null, so I went for something that's
more like Optional<Template> in Java 8, that is, always returning a
non-object that has a property to check if it represents something or
> It seems that, from an author's perspective, all we're doing here
> is deciding whether to throw an exception when the template is not found (or
> include nothing if ignore_missing is set) or to let the author handle the
> situation his own way.
> For me it might eliminate the need to provide Java support for default
> templates, something that is on my list to build. So it's a useful addition,
> if not super pretty.
> Other thoughts...
> The first thing that came to mind to ask whether it's practical to also use
> existing freemarker idiom. <#list> has similar use scenarios related to
> present, missing, alternate output.
> Sketchy conceptual example...
> <#include path,options>
> Stuff you want to output only if include is successful.
> Maybe more stuff to output for successful includes.
> Stuff you want to do if include failed, for whatever reason.
> I guess a problem with this is that <#include> is currently expected to be a
> self closing element with no content, and since ftl does not appear to use
> or require self closing elements like <#include/> it would be a pain to
> interpret whether <#include> has content or not.
Exactly. It's also not very good for the user (and for tooling).
> Forcing it to have content or include a closing tag would be a big
> breaking change. Is that the reasoning you would apply to this
Not only that. The problem is with the case where you need to do
something before the inclusion if the template exists. For that, above
you had to introduce a new directive, #included, which is pretty a
"heavy" solution for an otherwise quite language-agonistic problem. I
mean, in any usual programming language you do something like
`Template tOrNull = cfg.getTemplate(blah, allowMissing=true)`, then if
the result is non-null, do the include/import with some API using that
earlier returned Template. Pretty basic thing, no special statement
was needed. The solution proposed by me does the same, except that in
FTL we have to:
- Fight the inability of assigning null to a target variable (hence
it's a hash). (FM3: This will be solved there.)
- Fight the inability to call advanced FreeMarker API-s on a Template
object from a template (which is fine), but hence it's a hash again,
so it can contain those "utilities".
- Face how strange the special-variable syntax is (initial dot). BTW,
we have the same problem with
https://issues.apache.org/jira/browse/FREEMARKER-86 (FM3: This
syntax has to go, especially as it also leads to ambiguities, as in
the case `maybeNull!.someProp`.)
> Is Freemarker's approach to self-closing elements like <#include> likely to
> change in Freemarker 3?
There's no such plan for the default (HTML-ish) syntax at least.
> I didn't see anything about that in a quick review of the web page
> on FM3. Maybe you don't even think of these directives as elements.
> For a user familiar with HTML or XML it's hard to think of them
Yes, that was the intention. I never liked that though. But I intend
to remain true to the idea of the original authors anyway. However, I
will want to play with an alternative syntax, one that doesn't pretend
to be similar to HTML while it's actually not similar at all.
Something that a feels bit like WebMacro syntax.