[
https://issues.apache.org/jira/browse/FREEMARKER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17023581#comment-17023581
]
Dániel Dékány edited comment on FREEMARKER-112 at 1/25/20 2:20 PM:
-------------------------------------------------------------------
Getting the list of variables accessed by the template is a common request. But
it's not possible to do reliably (except in some subset of templates), because
what users mostly need is the list of variables that should be present in the
data-model. Given the dynamic nature of the template language, it's hard or
impossible to tell if on run-time the resolution of a variable will fall back
to the data-model, or it will be always already shadowed by an {{#assign}}-ed
variable, etc. Also, if you have things like {{.vars[someName]}}, {{?eval}},
etc., static analysis will be even more inaccurate.
But, surely we could provide an API that makes a "best effort", with clear
disclaimers in the related API. (I just never got there, with all the stuff in
the queue... And BTW, one goal of FM3 is to make such analysis possible. That's
why I want to make variable resolution more "static" there.)
As of exposing the whole AST API, again, there's clearly a user demand for
that. Even for transforming templates, or building them with Java API. Problem
is, in FM2 that API is a mess. Actually, the syntax itself is somewhat a messy,
and then it has a somewhat messy implementation, and so the two together... you
get it. And while that API is not publ+ished+, it's partially public, and so I
don't even dare to clean it up in FM2. Even if it wasn't a mess, exposing such
API can make evolution hard, as it's more likely that backward compatibility
requirements will be in your way. So my though back then was to create a nice
published API, that internally maps to the internal messy AST... but of course
that's a lot of work, and I could find the energy/time. But, here things
changed for the better... Given 2.x API is pretty much frozen, and FM3 is
wildly incompatible anyway, we might as well expose that awkward AST. Because I
don't dare to change it anyway, so what's the point of pretending that we don't
guarantee backward compatibility there. We in fact did. (How to do the same in
FM3 is a different question, because I don't want to expose the actual AST for
reasons stated above. But that's one reason why I think a much more regular
syntax/semantics is a critical feature of FM3, even if only a planned
feature...)
was (Author: ddekany):
Getting the list of variables accessed by the template is a common request. But
it's not possible to do reliably (except in some subset of templates), because
what users mostly need is the list of variables that should be present in the
data-model. Given the dynamic nature of the template language, it's hard or
impossible to tell if on run-time the resolution of a variable will fall back
to the data-model, or it will be always already shadowed by an {{#assign}}-ed
variable, etc. Also, if you have things like {{.vars[someName]}}, {{?eval}},
etc., static analysis will be even more inaccurate.
But, surely we could provide an API that makes a "best effort", with clear
disclaimers in the related API. (I just never got there, with all the stuff in
the queue... And BTW, one goal of FM3 is to make such analysis is possible.
That's why I want to make variable resolution more "static" there.)
As of exposing the whole AST API, again, there's clearly an user demand for
that. Even for transforming templates, or building them with Java API. Problem
is, in FM2 that API is a mess. Actually, the syntax itself is somewhat a messy,
and then it has a somewhat messy implementation, and so the two together... you
get it. And while that API is not publ+ished+, it's partially public, and so I
don't even dare to clean it up in FM2. Even if it wasn't a mess, exposing such
API can make evolution hard, as it's more likely that backward compatibility
requirements will be in your way. So my though back then was to create a nice
published API, that internally maps to the internal messy AST... but of course
that's a lot of work, and I could find the energy/time. But, here things
changed for the better... Given 2.x API is pretty much frozen, and FM3 is
wildly incompatible anyway, we might as well expose that awkward AST. Because I
don't dare to change it anyway, so what's the point of pretending that we don't
guarantee backward compatibility there. We in fact did. (How to do the same in
FM3 is a different question, because I don't want to expose the actual AST for
reasons stated above. But that's one reason why I think a much more regular
syntax is a critical feature of FM3, even if only a planned feature...)
> Inspect Freimarken Variables in Template for e.g. Testing
> ---------------------------------------------------------
>
> Key: FREEMARKER-112
> URL: https://issues.apache.org/jira/browse/FREEMARKER-112
> Project: Apache Freemarker
> Issue Type: Wish
> Components: engine
> Affects Versions: 2.3.28
> Environment: ALL
> Reporter: Yuna Morgenstern
> Assignee: Siegfried Goeschl
> Priority: Critical
> Labels: easyfix
> Fix For: 2.3.29
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> h5. Story
> As tester and backend tool developer
> we wish to inspect variables of a template
> so that we can test template structure before rendering, while testing and
> can present internally a gui tool which will show all variables, default
> values and all that stuff
> h5. Description
> FreeMarker already scans the template, so why not giving access to the parsed
> elements? It would be sad if we have to implement the same parsing logic as
> FreeMarker already does.
> h5. Acceptance criteria
> * parsed elements like e.g. freemarker.core.* can be accessed by e.g.
> (freemarker.coreTemplate.getRootTreeNode().getVariables() )
> * Variables are having types like, optional, required, predefined/constant,...
> * Variables are having default parameter which can be reached by another
> getter
> h5. Links example
> https://stackoverflow.com/questions/1919189/how-can-i-introspect-a-freemarker-template-to-find-out-what-variables-it-uses
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
