Re: Extensions to allow introspection of Freemarker template

Thanks for the clarification. I had been looking at the master branch, not the 2.3-gae branch, so I did not realize you had added the additional access methods. I will use those methods in the future.

Here are my short term plans. Because I am not yet ready to upgrade to the latest Freemarker version, I will initially build a proof of concept that uses introspection to access non-public fields. No classes will live in the freemarker.core package. This implementation will be suboptimal, obviously, but it will serve to get the API out for review. I also want to prove to myself that my objectives can be met. So, don't be alarmed when I push out something that is rather rough. It's the public API that matters. Later, I will revise it to fit better with Freemarker.

Speaking of fitting with Freemarker, how long do you intend to maintain pre-1.5 JDK support? I thought I had been conservative in my coding, but realize I've been using a few JDK 1.5 language constructs.

Chris

-----Original Message-----
From: Daniel Dekany [mailto:[email protected]]
Sent: Friday, May 30, 2014 4:27 PM
To: FreeMarker-devel
Subject: Re: [Freemarker-devel] 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
_______________________________________________
FreeMarker-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech