Re: Extensions to allow introspection of Freemarker template

Thursday, May 29, 2014, 10:03:51 PM, Wong, Christopher wrote:

> Thanks for responding at length. I am willing to proceed based on
> the direction you outlined below and set up a new freemarker-introspection project.
>
> I understand your wanting to keep new code from a total stranger at
> arm's length for now, but there will be challenges to maintaining a
> separate project.

My goal is to have something that can become the part of the
FreeMarker project, and then of course the maintenance will not be a
problem. For that, however, first the API need to be unpublished,
until it's mature enough so that we can promise backward
compatibility. It's not just about who contributes it. I wish
FreeMarker was this conservative earlier too.

Even when it becomes mature, it's not necessarily a good idea to bloat
freemarker.jar any further with functions that 99% of the users don't
need. It's bloated enough as it is (historical baggage again...have
plans to fix that too anyway). But being a separate jar doesn't mean
that it won't be kept in sync with the main artifact. It's just
modularisation.

> Obviously, since I cannot directly implement introspection support
> in the concrete nodes I should implement them as wrappers around the
> ones in freemarker.core.

To prevent any misunderstandings, I myself wouldn't implement
introspection support *directly* with those internal classes either.
Especially right now, with all that aging stuff there.

> The main problem I see here, though, is that even within the
> freemarker.core package access to expressions is practically
> nonexistent. What I mean is that while it's easy enough to navigate
> within subclasses of TemplateElement, it's not possible go any
> deeper to look at subclasses of Expression.

I have just added support for that in 2.3.20 (the stable release from
last summer). You can get the expression nodes with
TemplateObject.getParameterValue. You may also find ASTPrinter under
src/test useful. It's possible that there are some oversights etc.,
after all it wasn't used much yet. If you find any blockers or have
any recommendations, I will improve this internal API, as time allows.

> Take for example DollarVariable: it might express something like
> "${foo.bar}". There is a Dot expression in there for "foo.bar" that
> in turn contains an Identifier expression for "foo" ... but none of
> that is visible to me because DollarVariable's expression is
> private. It's not possible to answer interesting questions like
> "what identifiers are present in this template?" I could use
> reflection to break through, but I'd rather use getters on these
> classes. For example:
>
> ComparisonExpression:
> - Expression getLeft()
> - Expression getRight()
> - int getOperation()
>
> Would you consider such changes if I sent you a pull request?

That's certainly not necessary as I said above. But, speaking of pull
requests, you need to sign a Contributor Licence Agreement before any
code of you can get into FreeMarker. Just the standard stuff... your
employer won't claim that the code is theirs etc. I will send it over.

> Chris
>
> -----Original Message-----
> (...)
>
> So, I guess we should define interfaces that show the contents of a
> template in a future proof (an thus high level) and intuitive way.
> If the currently used AST nodes can be changed to implement those
> interfaces, that's a plus of course, but the point is exactly that
> they don't have to able to do so. At least for the first iteration,
> I'm thinking about something really lightweight and "dynamic", where
> you don't have a sub-interface for each kind of AST nodes (there's a
> ton of them, and more can come anytime), instead, you can just get
> what kind of node is that (built-in directive, operator, etc.) and a
> string that gives its name ("include", "+", etc.) and it's
> parameters/operands. This thing could be in another project, let's
> say, freemarker-introspection. This kind of feature would be useful
> for IDE-s too, for outline views and so on. Some of the classes in
> freemarker-introspection will have to be inside freemarker.core, but
> if it turns out to be something good, then it will be maintained
> together with FreeMarker, so then you have backward compatibility guarantee after all.
>
> --
> Thanks,
>  Daniel Dekany

-- 
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet