Re: Extensions to allow introspection of Freemarker template

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. Obviously, since I cannot directly implement introspection support in the concrete nodes I should  implement them as wrappers around the ones in freemarker.core. 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. 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?

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 use
 ful 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


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.

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