Quantcast

Extensions to allow introspection of Freemarker template

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Extensions to allow introspection of Freemarker template

Wong, Christopher

I work with user-submitted templates, and would like Freemarker support some form of introspection of a template. For example, I might want to know what identifiers the template will request from the model. Freemarker already has something very close to this: the public method Template.getRootTreeNode exposes a DOM-like structure the end user. Unfortunately, the TemplateElement classes that comes back are mostly not visible to the public.

 

Since I'd rather not fork an internal copy of Freemarker, I'd like to explore the possibility of contributing changes to the Freemarker project to enable template introspection. I want to see if there's an approach that the maintainers will find acceptable.

 

1) The easiest way to accomplish this is to make the TemplateElement hierarchy public and add public getters to these classes. On the other hand, this might expose more than you'd like. 2) You have implemented similar functionality by having this class implement the TreeNode interface to expose this tree as a Swing component. Perhaps a separate interface hierarchy will provide acceptable decoupling?



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.

------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

Daniel Dekany
Tuesday, May 27, 2014, 3:58:05 PM, Wong, Christopher wrote:

> I work with user-submitted templates, and would like Freemarker
> support some form of introspection of a template. For example, I
> might want to know what identifiers the template will request from
> the model.

Note that in general it's impossible to tell if a variable refers to a
data-model variable, or a something more local. #assign, #global, and
even #local shadow the data-model only after it was executed. (That's
BTW why I want to deprecate them in the far future... the sabotage
static analysis.)

> Freemarker already has something very close to this: the
> public method Template.getRootTreeNode exposes a DOM-like structure
> the end user. Unfortunately, the TemplateElement classes that comes
> back are mostly not visible to the public.
>  
> Since I'd rather not fork an internal copy of Freemarker, I'd like
> to explore the possibility of contributing changes to the Freemarker
> project to enable template introspection.

You can create classes that are inside the freemarker.core package in
your own project, and then those classes can access all those AST
nodes. No need for forking for that. Of course, the problem with that
approach is that there's no backward compatibility guarantee for the
internal classes. But then, doing this hack is still more maintainable
than a fork.

> I want to see if there's an approach that the maintainers will find
> acceptable.
>  
> 1) The easiest way to accomplish this is to make the
> TemplateElement hierarchy public and add public getters to these
> classes. On the other hand, this might expose more than you'd like.

Yes, that's a problem... Those internal classes are a bit of a mess
too.

> 2) You have implemented similar functionality by having this class
> implement the TreeNode interface to expose this tree as a Swing
> component. Perhaps a separate interface hierarchy will provide acceptable decoupling?

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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

Wong, Christopher
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 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


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
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

David Levine-2
In reply to this post by Wong, Christopher
Hello Christopher,

Do you want to parse the freemarker HTML to pull out the freemarker variable references so you can create a data model that will work for any given freemarker template?  I can see why you'd want to do that.  You need want to live with some restrictions in terms of what you might pick up automatically by introspection.

In our case, what we do is define the data model separately in an XML file, such that the data model matches what the form expects.  From that data model, we generate a form that a user can fill out, and from that form input we generate the data model which will match what the HTML expects (in terms of Freemarker variable references).

Hope that helps!

David


On Tue, May 27, 2014 at 6:58 AM, Wong, Christopher <[hidden email]> wrote:

I work with user-submitted templates, and would like Freemarker support some form of introspection of a template. For example, I might want to know what identifiers the template will request from the model. Freemarker already has something very close to this: the public method Template.getRootTreeNode exposes a DOM-like structure the end user. Unfortunately, the TemplateElement classes that comes back are mostly not visible to the public.

 

Since I'd rather not fork an internal copy of Freemarker, I'd like to explore the possibility of contributing changes to the Freemarker project to enable template introspection. I want to see if there's an approach that the maintainers will find acceptable.

 

1) The easiest way to accomplish this is to make the TemplateElement hierarchy public and add public getters to these classes. On the other hand, this might expose more than you'd like. 2) You have implemented similar functionality by having this class implement the TreeNode interface to expose this tree as a Swing component. Perhaps a separate interface hierarchy will provide acceptable decoupling?



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.

------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

Daniel Dekany
In reply to this post by Wong, Christopher
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

Wong, Christopher
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:[hidden email]]
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
[hidden email]
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
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

Wong, Christopher
In reply to this post by David Levine-2

Thanks for the feedback, David. Your approach will work if you have some control over the data model. That is unfortunately not an option for me right now, but it’s great that you can take that approach.

 

Chris

 

 

From: David Levine [mailto:[hidden email]]
Sent: Thursday, May 29, 2014 4:10 PM
To: FreeMarker-devel
Subject: Re: [Freemarker-devel] Extensions to allow introspection of Freemarker template

 

Hello Christopher,

 

Do you want to parse the freemarker HTML to pull out the freemarker variable references so you can create a data model that will work for any given freemarker template?  I can see why you'd want to do that.  You need want to live with some restrictions in terms of what you might pick up automatically by introspection.

 

In our case, what we do is define the data model separately in an XML file, such that the data model matches what the form expects.  From that data model, we generate a form that a user can fill out, and from that form input we generate the data model which will match what the HTML expects (in terms of Freemarker variable references).

 

Hope that helps!

 

David



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
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

Daniel Dekany
In reply to this post by Wong, Christopher
Monday, June 2, 2014, 4:59:12 PM, Wong, Christopher wrote:

> Thanks for the clarification. I had been looking at the master
> branch, not the 2.3-gae branch,

(Hm... somehow I will have to get rid of that 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,

(Note that 2.3.x releases meant to be backward compatible, so it
shouldn't be a big deal.)

> I will initially build a proof of concept that uses introspection to
> access non-public fields.

Well... I recommend for your own sake to develop against 2.3.20 (or
the 2.3-gae trunk). Also, then its package-visible AST API can become
more mature too.

> No classes will live in the freemarker.core package.

Why not, BTW? Better than reflection...

> 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?

Well, I don't really want to any longer, but until 2.4.0 I should to,
because backward compatibility breaking is only supposed to happen
when the 2nd version number changes... After 2.3.21 I want to start
focusing on 2.4 (which will require Java 6), but it can be a long time
until it will be released.

> I thought I had been conservative in my coding, but realize I've
> been using a few JDK 1.5 language constructs.

Since that's a separate jar anyway, you can use Java 5 there.

> Chris
>
> -----Original Message-----
> From: Daniel Dekany [mailto:[hidden email]]
> 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
> [hidden email]
> 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
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

--
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
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
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Extensions to allow introspection of Freemarker template

Wong, Christopher
I have pushed out a rough initial implementation of freemarker-introspection. It's really more of a proof of concept, but I thought it might be useful to solicit feedback.

https://github.com/cwong15/freemarker-introspection

The current implementation uses an introspection approach to access Freemarker properties. We both know this is not the right approach going forward, and I consider this temporary code. Eventually, I intend to use the package-local access wherever feasible.

Chris

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
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Loading...