date:20170811

[jira] [Closed] (FREEMARKER-67) Doesn't support org.bson.Document's correct order of keys.

2017-08-11 Thread Daniel Dekany (JIRA)


 [ 
https://issues.apache.org/jira/browse/FREEMARKER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Dekany closed FREEMARKER-67.
---

> Doesn't support org.bson.Document's correct order of keys.
> --
>
> Key: FREEMARKER-67
> URL: https://issues.apache.org/jira/browse/FREEMARKER-67
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.23, 2.3.24-incubating, 2.3.25-incubating, 
> 2.3.26-incubating
> Environment: Windows7, jdk1.8.0_131 64bit, Tomcat 8.0.45, SpringMVC 
> 4.3.10.RELEASE, mongo-java-driver 3.4.2
>Reporter: Pu Zhongqiang
>Priority: Minor
>  Labels: features
> Fix For: 2.3.23, 2.3.24-incubating, 2.3.25-incubating, 
> 2.3.26-incubating
>
>
> In mongodb's Java Driver 3.x, org.bson.Document is a representation of a bson 
> document as a Map. Although org.bson.Document is not a subclass of 
> LinkedHashMap, it really DOES maintain a meaningful order for its keys.
> It works good if I use LinkedHashMap to load data.
> {code:java}
> LinkedHashMap accepted_sorts = new LinkedHashMap<>();
> accepted_sorts.put("-favorite_time", "Hello");
> accepted_sorts.put("-publish_time", "Welcome");
> model.put("accepted_sorts", accepted_sorts);
> {code}
> {code:html}
> <#list accepted_sorts?keys as value>
>   ${value?string}
> 
> 
> <#list accepted_sorts as key,value>
>   ${key?string},${value?string}
> 
> {code}
> it rendered as: 
> {code:html}
> -favorite_time -publish_time 
> -favorite_time,Hello -publish_time,Welcome 
> {code}
> But Freemarker doesn't support  org.bson.Document's correct key order. You 
> can see my test below:
> {code:java}
> Document accepted_sorts = new Document();
> accepted_sorts.put("-favorite_time", "Hello");
> accepted_sorts.put("-publish_time", "Welcome");
> model.put("accepted_sorts", accepted_sorts);
> {code}
> {code:html}
> <#list accepted_sorts?keys as value>
>   ${value?string}
> 
> 
> <#list accepted_sorts as key,value>
>   ${key?string},${value?string}
> 
> {code}
> it rendered as wrong order: 
> {code:html}
> -publish_time -favorite_time 
> -publish_time,Welcome -favorite_time,Hello 
> {code}
> So, in the end, I wish freemarker can add support for org.bson.Document's 
> correct order of keys.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123117#comment-16123117
 ] 

Daniel Dekany edited comment on FREEMARKER-68 at 8/11/17 10:02 AM:
---

The problem is not specific to {{\?\?}} actually. The way it works is that 
{{freemarker.ext.jython.JythonModel.get(String)}} is called (which is just an 
implementation of {{TemplateHashModel.get(String)}} as far as FreeMarker is 
concerned), and then if that returns {{null}} then {{\?\?}} or the other 
existence handlers operators (most notably {{exp!defaultExp}}) handle it. That 
particular {{get}} implementation calls {{PyObject.\_\_findattr\_\_(key)}}, and 
if that returns {{null}} then it also tries {{PyObject.\_\_finditem\_\_(key)}}. 
If both was {{null}}, then {{get}} returns {{null}}, and {{\?\?}} works. I'm 
not sure what the proper {{PyObject}} calls would be... And frankly, I think 
that the Jython wrapper is some early implementation hastily dropped in back 
then by the earlier developers, maybe to catch some attention from then much 
more active Jython community, but then it was practically abandoned. But as its 
part of {{freemarker.jar}}, it stuck there for backward compatibility. So I can 
imagine there's a lot to improve there. If anyone cares to improve it (or even 
create an external wrapper that's better, as then there are no backward 
compatibility constraints), it's highly welcome. Similarly here, it's not 
likely that anything will happen without a Pull Request or patch, which also 
considers backward compatibility (means, certainly we will need to add 
{{incompatibleImprovements}} setting to the {{JythonWrapper}}, similarly as 
{{DefaultObjectWrapper}} has it too).


was (Author: ddekany):
The problem is not specific to {{\?\?}} actually. The way it works is that 
{{freemarker.ext.jython.JythonModel.get(String)}} is called (which is just an 
implementation of {{TemplateHashModel.get(String)}} as far as FreeMarker is 
concerned), and then if that returns {{null}} then {{\?\?}} or the other 
existence handlers operators (most notably {{exp!defaultExp}}) handle it. That 
particular {{get}} implementation calls {{PyObject.__findattr__(key)}}, and if 
that returns {{null}} then it also tries {{PyObject.__finditem__(key)}}. If 
both was {{null}}, then {{get}} returns {{null}}, and {{\?\?}} works. I'm not 
sure what the proper {{PyObject}} calls would be... And frankly, I think that 
the Jython wrapper is some early implementation hastily dropped in back then by 
the earlier developers, maybe to catch some attention from then much more 
active Jython community, but then it was practically abandoned. But as its part 
of {{freemarker.jar}}, it stuck there for backward compatibility. So I can 
imagine there's a lot to improve there. If anyone cares to improve it (or even 
create an external wrapper that's better, as then there are no backward 
compatibility constraints), it's highly welcome. Similarly here, it's not 
likely that anything will happen without a Pull Request or patch, which also 
considers backward compatibility (means, certainly we will need to add 
{{incompatibleImprovements}} setting to the {{JythonWrapper}}, similarly as 
{{DefaultObjectWrapper}} has it too).

> Double-question mark operator does not properly test for attributes
> ---
>
> Key: FREEMARKER-68
> URL: https://issues.apache.org/jira/browse/FREEMARKER-68
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.23
>Reporter: Jason Sachs
>
> The double-question mark operator doesn't work properly with some Jython 
> objects.
> It works properly with dicts.
> It does not work properly with custom classes and triggers an item lookup.
> Example setup: (I can't post a complete self-contained example, sorry)
> Jython code called before FreeMarker template is rendered:
> {code}
> class VoodooDoll(object):
> def pinch(self):
> return "ouch"
> model['test1'] = dict(voodooDoll=VoodooDoll())
> {code}
> FreeMarker template:
> {code}
> <#if test1.blah??>
> blah present
> 
> <#if test1.voodooDoll??>
> voodoo doll present
> 
> <#if test1.voodooDoll.pinch??>
> voodoo doll pinch present
> 
> <#if test1.voodooDoll.hit??>
> voodoo doll hit present
> 
> {code}
> This produces the output
> {noformat}
> voodoo doll present
> voodoo doll pinch present
> {noformat}
> so the first three {{#if}} tests work properly, but the fourth one causes 
> this error:
> {noformat}
>   - Failed at: #if test1.voodooDoll.hit??  [in template 
> "source\\aux-files\\parameters.html.template" at line 58, column 1]
> ...
> Caused by: TypeError: 'VoodooDoll' object is unsubscriptable
>   at org.python.core.Py.TypeError(Py.java:235)
>   at

[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123117#comment-16123117
 ] 

Daniel Dekany edited comment on FREEMARKER-68 at 8/11/17 10:02 AM:
---

The problem is not specific to {{\?\?}} actually. The way it works is that 
{{freemarker.ext.jython.JythonModel.get(String)}} is called (which is just an 
implementation of {{TemplateHashModel.get(String)}} as far as FreeMarker is 
concerned), and then if that returns {{null}} then {{\?\?}} or the other 
existence handlers operators (most notably {{exp!defaultExp}}) handle it. That 
particular {{get}} implementation calls {{PyObject.__findattr__(key)}}, and if 
that returns {{null}} then it also tries {{PyObject.__finditem__(key)}}. If 
both was {{null}}, then {{get}} returns {{null}}, and {{\?\?}} works. I'm not 
sure what the proper {{PyObject}} calls would be... And frankly, I think that 
the Jython wrapper is some early implementation hastily dropped in back then by 
the earlier developers, maybe to catch some attention from then much more 
active Jython community, but then it was practically abandoned. But as its part 
of {{freemarker.jar}}, it stuck there for backward compatibility. So I can 
imagine there's a lot to improve there. If anyone cares to improve it (or even 
create an external wrapper that's better, as then there are no backward 
compatibility constraints), it's highly welcome. Similarly here, it's not 
likely that anything will happen without a Pull Request or patch, which also 
considers backward compatibility (means, certainly we will need to add 
{{incompatibleImprovements}} setting to the {{JythonWrapper}}, similarly as 
{{DefaultObjectWrapper}} has it too).


was (Author: ddekany):
The problem is not specific to {{\?\?}} actually. That way it works is that 
{{freemarker.ext.jython.JythonModel.get(String)}} is called (which is just an 
implementation of {{TemplateHashModel.get(String)}} as far as FreeMarker is 
concerned), and then if that returns {{null}} then {{??}} or the other 
existence handlers operators (most notably {{exp!defaultExp}}) handle it. That 
particular {{get}} implementation calls {{PyObject.__findattr__(key)}}, and if 
that returns {{null}} then it also tries {{PyObject.__finditem__(key)}}. If 
both was {{null}}, then {{get}} returns {{null}}, and {{??}} works. I'm not 
sure what the proper {{PyObject}} calls would be... And frankly, I think that 
the Jython wrapper is some early implementation hastily dropped in back then by 
the earlier developers, maybe to catch some attention from then much more 
active Jython community, but then it was practically abandoned. But as its part 
of {{freemarker.jar}}, it stuck there for backward compatibility. So I can 
imagine there's a lot to improve there. If anyone cares to improve it (or even 
create an external wrapper that's better, as then there are no backward 
compatibility constraints), it's highly welcome. Similarly here, it's not 
likely that anything will happen without a Pull Request or patch, which also 
considers backward compatibility (means, certainly we will need to add 
{{incompatibleImprovements}} setting to the {{JythonWrapper}}, similarly as 
{{DefaultObjectWrapper}} has it too).

> Double-question mark operator does not properly test for attributes
> ---
>
> Key: FREEMARKER-68
> URL: https://issues.apache.org/jira/browse/FREEMARKER-68
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.23
>Reporter: Jason Sachs
>
> The double-question mark operator doesn't work properly with some Jython 
> objects.
> It works properly with dicts.
> It does not work properly with custom classes and triggers an item lookup.
> Example setup: (I can't post a complete self-contained example, sorry)
> Jython code called before FreeMarker template is rendered:
> {code}
> class VoodooDoll(object):
> def pinch(self):
> return "ouch"
> model['test1'] = dict(voodooDoll=VoodooDoll())
> {code}
> FreeMarker template:
> {code}
> <#if test1.blah??>
> blah present
> 
> <#if test1.voodooDoll??>
> voodoo doll present
> 
> <#if test1.voodooDoll.pinch??>
> voodoo doll pinch present
> 
> <#if test1.voodooDoll.hit??>
> voodoo doll hit present
> 
> {code}
> This produces the output
> {noformat}
> voodoo doll present
> voodoo doll pinch present
> {noformat}
> so the first three {{#if}} tests work properly, but the fourth one causes 
> this error:
> {noformat}
>   - Failed at: #if test1.voodooDoll.hit??  [in template 
> "source\\aux-files\\parameters.html.template" at line 58, column 1]
> ...
> Caused by: TypeError: 'VoodooDoll' object is unsubscriptable
>   at org.python.core.Py.TypeError(Py.java:235)
>   at

[jira] [Commented] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123117#comment-16123117
 ] 

Daniel Dekany commented on FREEMARKER-68:
-

The problem is not specific to {{??}} actually. That way it works is that 
{{freemarker.ext.jython.JythonModel.get(String)}} is called (which is just an 
implementation of {{TemplateHashModel.get(String)}} as far as FreeMarker is 
concerned), and then if that returns {{null}} then {{??}} or the other 
existence handlers operators (most notably {{exp!defaultExp}}) handle it. That 
particular {{get}} implementation calls {{PyObject.__findattr__(key)}}, and if 
that returns {{null}} then it also tries {{PyObject.__finditem__(key)}}. If 
both was {{null}}, then {{get}} returns {{null}}, and {{??}} works. I'm not 
sure what the proper {{PyObject}} calls would be... And frankly, I think that 
the Jython wrapper is some early implementation hastily dropped in back then by 
the earlier developers, maybe to catch some attention from then much more 
active Jython community, but then it was practically abandoned. But as its part 
of {{freemarker.jar}}, it stuck there for backward compatibility. So I can 
imagine there's a lot to improve there. If anyone cares to improve it (or even 
create an external wrapper that's better, as then there are no backward 
compatibility constraints), it's highly welcome. Similarly here, it's not 
likely that anything will happen without a Pull Request or patch, which also 
considers backward compatibility (means, certainly we will need to add 
{{incompatibleImprovements}} setting to the {{JythonWrapper}}, similarly as 
{{DefaultObjectWrapper}} has it too).

> Double-question mark operator does not properly test for attributes
> ---
>
> Key: FREEMARKER-68
> URL: https://issues.apache.org/jira/browse/FREEMARKER-68
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.23
>Reporter: Jason Sachs
>
> The double-question mark operator doesn't work properly with some Jython 
> objects.
> It works properly with dicts.
> It does not work properly with custom classes and triggers an item lookup.
> Example setup: (I can't post a complete self-contained example, sorry)
> Jython code called before FreeMarker template is rendered:
> {code}
> class VoodooDoll(object):
> def pinch(self):
> return "ouch"
> model['test1'] = dict(voodooDoll=VoodooDoll())
> {code}
> FreeMarker template:
> {code}
> <#if test1.blah??>
> blah present
> 
> <#if test1.voodooDoll??>
> voodoo doll present
> 
> <#if test1.voodooDoll.pinch??>
> voodoo doll pinch present
> 
> <#if test1.voodooDoll.hit??>
> voodoo doll hit present
> 
> {code}
> This produces the output
> {noformat}
> voodoo doll present
> voodoo doll pinch present
> {noformat}
> so the first three {{#if}} tests work properly, but the fourth one causes 
> this error:
> {noformat}
>   - Failed at: #if test1.voodooDoll.hit??  [in template 
> "source\\aux-files\\parameters.html.template" at line 58, column 1]
> ...
> Caused by: TypeError: 'VoodooDoll' object is unsubscriptable
>   at org.python.core.Py.TypeError(Py.java:235)
>   at org.python.core.PyObject.__finditem__(PyObject.java:585)
>   at 
> org.python.core.PyObjectDerived.__finditem__(PyObjectDerived.java:861)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123223#comment-16123223
 ] 

Daniel Dekany edited comment on FREEMARKER-69 at 8/11/17 11:43 AM:
---

It's a design decision in FreeMarker that user defined directives (including 
macros) and user defined functions are just variables. They all use the same 
namespace.  To be more precise, directives and functions are first class 
values, that is, you can pass them around just like strings or numbers or 
anything else. So with {{<#macro foo>}} you create a value of type macro, and 
then assign that to the variable {{foo}} (similarly as {{<#assign foo = ...>}}).

Many other languages do the same, but of course different people prefer 
different approaches (hence I marked this as "Not A Problem"). But surely 
changing this is not backward compatible.


was (Author: ddekany):
It's a design decision in FreeMarker that user defined directives (including 
macros) and user defined functions are just variables. They all use the same 
namespace.  To be more precise, directives and functions are first class 
values, that is, you can pass them around just like strings or numbers or 
anything else. So with {{<#macro foo>}} you create a value of type macro, and 
then assign that to the variable {{foo}} (similarly as {{<#assign foo = ...>}}).

Many other languages does the same, but of course different people prefer 
different approaches. But surely changing this is not backward compatible.

> Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The  
> user-defined directive key same as Variable key 
> --
>
> Key: FREEMARKER-69
> URL: https://issues.apache.org/jira/browse/FREEMARKER-69
> Project: Apache Freemarker
>  Issue Type: Bug
>Reporter: pengzhistar
>Priority: Minor
> Attachments: Freemarker.rar
>
>
> Exception info:
> For "@" callee: Expected a(n) user-defined directive, transform or macro, but 
> this has evaluated to a sequence (wrapper: f.t.SimpleSequence): 
> Advise:
> Chinese：将directive对象和临时变量对象分开存储
> English： Separately store directive objects and temporary variable objects 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123117#comment-16123117
 ] 

Daniel Dekany edited comment on FREEMARKER-68 at 8/11/17 10:00 AM:
---

The problem is not specific to {{\?\?}} actually. That way it works is that 
{{freemarker.ext.jython.JythonModel.get(String)}} is called (which is just an 
implementation of {{TemplateHashModel.get(String)}} as far as FreeMarker is 
concerned), and then if that returns {{null}} then {{??}} or the other 
existence handlers operators (most notably {{exp!defaultExp}}) handle it. That 
particular {{get}} implementation calls {{PyObject.__findattr__(key)}}, and if 
that returns {{null}} then it also tries {{PyObject.__finditem__(key)}}. If 
both was {{null}}, then {{get}} returns {{null}}, and {{??}} works. I'm not 
sure what the proper {{PyObject}} calls would be... And frankly, I think that 
the Jython wrapper is some early implementation hastily dropped in back then by 
the earlier developers, maybe to catch some attention from then much more 
active Jython community, but then it was practically abandoned. But as its part 
of {{freemarker.jar}}, it stuck there for backward compatibility. So I can 
imagine there's a lot to improve there. If anyone cares to improve it (or even 
create an external wrapper that's better, as then there are no backward 
compatibility constraints), it's highly welcome. Similarly here, it's not 
likely that anything will happen without a Pull Request or patch, which also 
considers backward compatibility (means, certainly we will need to add 
{{incompatibleImprovements}} setting to the {{JythonWrapper}}, similarly as 
{{DefaultObjectWrapper}} has it too).


was (Author: ddekany):
The problem is not specific to {{??}} actually. That way it works is that 
{{freemarker.ext.jython.JythonModel.get(String)}} is called (which is just an 
implementation of {{TemplateHashModel.get(String)}} as far as FreeMarker is 
concerned), and then if that returns {{null}} then {{??}} or the other 
existence handlers operators (most notably {{exp!defaultExp}}) handle it. That 
particular {{get}} implementation calls {{PyObject.__findattr__(key)}}, and if 
that returns {{null}} then it also tries {{PyObject.__finditem__(key)}}. If 
both was {{null}}, then {{get}} returns {{null}}, and {{??}} works. I'm not 
sure what the proper {{PyObject}} calls would be... And frankly, I think that 
the Jython wrapper is some early implementation hastily dropped in back then by 
the earlier developers, maybe to catch some attention from then much more 
active Jython community, but then it was practically abandoned. But as its part 
of {{freemarker.jar}}, it stuck there for backward compatibility. So I can 
imagine there's a lot to improve there. If anyone cares to improve it (or even 
create an external wrapper that's better, as then there are no backward 
compatibility constraints), it's highly welcome. Similarly here, it's not 
likely that anything will happen without a Pull Request or patch, which also 
considers backward compatibility (means, certainly we will need to add 
{{incompatibleImprovements}} setting to the {{JythonWrapper}}, similarly as 
{{DefaultObjectWrapper}} has it too).

> Double-question mark operator does not properly test for attributes
> ---
>
> Key: FREEMARKER-68
> URL: https://issues.apache.org/jira/browse/FREEMARKER-68
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.23
>Reporter: Jason Sachs
>
> The double-question mark operator doesn't work properly with some Jython 
> objects.
> It works properly with dicts.
> It does not work properly with custom classes and triggers an item lookup.
> Example setup: (I can't post a complete self-contained example, sorry)
> Jython code called before FreeMarker template is rendered:
> {code}
> class VoodooDoll(object):
> def pinch(self):
> return "ouch"
> model['test1'] = dict(voodooDoll=VoodooDoll())
> {code}
> FreeMarker template:
> {code}
> <#if test1.blah??>
> blah present
> 
> <#if test1.voodooDoll??>
> voodoo doll present
> 
> <#if test1.voodooDoll.pinch??>
> voodoo doll pinch present
> 
> <#if test1.voodooDoll.hit??>
> voodoo doll hit present
> 
> {code}
> This produces the output
> {noformat}
> voodoo doll present
> voodoo doll pinch present
> {noformat}
> so the first three {{#if}} tests work properly, but the fourth one causes 
> this error:
> {noformat}
>   - Failed at: #if test1.voodooDoll.hit??  [in template 
> "source\\aux-files\\parameters.html.template" at line 58, column 1]
> ...
> Caused by: TypeError: 'VoodooDoll' object is unsubscriptable
>   at org.python.core.Py.TypeError(Py.java:235)
>   at

[jira] [Updated] (FREEMARKER-68) Double-question mark operator does not properly test for Jython attributes

2017-08-11 Thread Daniel Dekany (JIRA)


 [ 
https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Dekany updated FREEMARKER-68:

Summary: Double-question mark operator does not properly test for Jython 
attributes  (was: Double-question mark operator does not properly test for 
attributes)

> Double-question mark operator does not properly test for Jython attributes
> --
>
> Key: FREEMARKER-68
> URL: https://issues.apache.org/jira/browse/FREEMARKER-68
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.23
>Reporter: Jason Sachs
>
> The double-question mark operator doesn't work properly with some Jython 
> objects.
> It works properly with dicts.
> It does not work properly with custom classes and triggers an item lookup.
> Example setup: (I can't post a complete self-contained example, sorry)
> Jython code called before FreeMarker template is rendered:
> {code}
> class VoodooDoll(object):
> def pinch(self):
> return "ouch"
> model['test1'] = dict(voodooDoll=VoodooDoll())
> {code}
> FreeMarker template:
> {code}
> <#if test1.blah??>
> blah present
> 
> <#if test1.voodooDoll??>
> voodoo doll present
> 
> <#if test1.voodooDoll.pinch??>
> voodoo doll pinch present
> 
> <#if test1.voodooDoll.hit??>
> voodoo doll hit present
> 
> {code}
> This produces the output
> {noformat}
> voodoo doll present
> voodoo doll pinch present
> {noformat}
> so the first three {{#if}} tests work properly, but the fourth one causes 
> this error:
> {noformat}
>   - Failed at: #if test1.voodooDoll.hit??  [in template 
> "source\\aux-files\\parameters.html.template" at line 58, column 1]
> ...
> Caused by: TypeError: 'VoodooDoll' object is unsubscriptable
>   at org.python.core.Py.TypeError(Py.java:235)
>   at org.python.core.PyObject.__finditem__(PyObject.java:585)
>   at 
> org.python.core.PyObjectDerived.__finditem__(PyObjectDerived.java:861)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

2017-08-11 Thread pengzhistar (JIRA)

pengzhistar created FREEMARKER-69:
-

 Summary: Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A 
bug when The  user-defined directive key same as Variable key 
 Key: FREEMARKER-69
 URL: https://issues.apache.org/jira/browse/FREEMARKER-69
 Project: Apache Freemarker
  Issue Type: Bug
Reporter: pengzhistar
Priority: Minor
 Attachments: Freemarker.rar

Exception info:
For "@" callee: Expected a(n) user-defined directive, transform or macro, but 
this has evaluated to a sequence (wrapper: f.t.SimpleSequence): 

Advise:
Chinese：将directive对象和临时变量对象分开存储
English： Separately store directive objects and temporary variable objects 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123223#comment-16123223
 ] 

Daniel Dekany edited comment on FREEMARKER-69 at 8/11/17 11:37 AM:
---

It's a design decision in FreeMarker that user refined directives (including 
macros) and user defined functions are just variables. They all use the same 
namespace.  To be more precise, directives and functions are first class 
values, that is, you can pass them around just like strings or numbers or 
anything else. So with {{<#macro foo>}} you create a value of type macro, and 
then assign that to the variable {{foo}} (similarly as {{<#assign foo = ...>}}).


was (Author: ddekany):
It's design decision in FreeMarker that user refined directives (including 
macros) and user defined functions are just variables. They all use the same 
namespace.  Also, directives and functions are first class values, that is, you 
can pass them around just like strings or numbers or anything else. So with 
{{<#macro foo>}} you really just create a value of type macro, and then assign 
it to variable {{foo}} (similarly as {{<#assign foo = ...>}}).

> Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The  
> user-defined directive key same as Variable key 
> --
>
> Key: FREEMARKER-69
> URL: https://issues.apache.org/jira/browse/FREEMARKER-69
> Project: Apache Freemarker
>  Issue Type: Bug
>Reporter: pengzhistar
>Priority: Minor
> Attachments: Freemarker.rar
>
>
> Exception info:
> For "@" callee: Expected a(n) user-defined directive, transform or macro, but 
> this has evaluated to a sequence (wrapper: f.t.SimpleSequence): 
> Advise:
> Chinese：将directive对象和临时变量对象分开存储
> English： Separately store directive objects and temporary variable objects 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123223#comment-16123223
 ] 

Daniel Dekany edited comment on FREEMARKER-69 at 8/11/17 11:41 AM:
---

It's a design decision in FreeMarker that user defined directives (including 
macros) and user defined functions are just variables. They all use the same 
namespace.  To be more precise, directives and functions are first class 
values, that is, you can pass them around just like strings or numbers or 
anything else. So with {{<#macro foo>}} you create a value of type macro, and 
then assign that to the variable {{foo}} (similarly as {{<#assign foo = ...>}}).

Many other languages does the same, but of course different people prefer 
different approaches. But surely changing this is not backward compatible.


was (Author: ddekany):
It's a design decision in FreeMarker that user refined directives (including 
macros) and user defined functions are just variables. They all use the same 
namespace.  To be more precise, directives and functions are first class 
values, that is, you can pass them around just like strings or numbers or 
anything else. So with {{<#macro foo>}} you create a value of type macro, and 
then assign that to the variable {{foo}} (similarly as {{<#assign foo = ...>}}).

> Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The  
> user-defined directive key same as Variable key 
> --
>
> Key: FREEMARKER-69
> URL: https://issues.apache.org/jira/browse/FREEMARKER-69
> Project: Apache Freemarker
>  Issue Type: Bug
>Reporter: pengzhistar
>Priority: Minor
> Attachments: Freemarker.rar
>
>
> Exception info:
> For "@" callee: Expected a(n) user-defined directive, transform or macro, but 
> this has evaluated to a sequence (wrapper: f.t.SimpleSequence): 
> Advise:
> Chinese：将directive对象和临时变量对象分开存储
> English： Separately store directive objects and temporary variable objects 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123223#comment-16123223
 ] 

Daniel Dekany commented on FREEMARKER-69:
-

It's design decision in FreeMarker that user refined directives (including 
macros) and user defined functions are just variables. They all use the same 
namespace.  Also, directives and functions are first class values, that is, you 
can pass them around just like strings or numbers or anything else. So with 
{{<#macro foo>}} you really just create a value of type macro, and then assign 
it to variable {{foo}} (similarly as {{<#assign foo = ...>}}).

> Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The  
> user-defined directive key same as Variable key 
> --
>
> Key: FREEMARKER-69
> URL: https://issues.apache.org/jira/browse/FREEMARKER-69
> Project: Apache Freemarker
>  Issue Type: Bug
>Reporter: pengzhistar
>Priority: Minor
> Attachments: Freemarker.rar
>
>
> Exception info:
> For "@" callee: Expected a(n) user-defined directive, transform or macro, but 
> this has evaluated to a sequence (wrapper: f.t.SimpleSequence): 
> Advise:
> Chinese：将directive对象和临时变量对象分开存储
> English： Separately store directive objects and temporary variable objects 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

2017-08-11 Thread Daniel Dekany (JIRA)


 [ 
https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Dekany resolved FREEMARKER-69.
-
Resolution: Not A Problem

> Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The  
> user-defined directive key same as Variable key 
> --
>
> Key: FREEMARKER-69
> URL: https://issues.apache.org/jira/browse/FREEMARKER-69
> Project: Apache Freemarker
>  Issue Type: Bug
>Reporter: pengzhistar
>Priority: Minor
> Attachments: Freemarker.rar
>
>
> Exception info:
> For "@" callee: Expected a(n) user-defined directive, transform or macro, but 
> this has evaluated to a sequence (wrapper: f.t.SimpleSequence): 
> Advise:
> Chinese：将directive对象和临时变量对象分开存储
> English： Separately store directive objects and temporary variable objects 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[3/3] incubator-freemarker git commit: Bug fixed (FREEMARKER-70): The usage of loop variable built-ins, like loopVar?index, was disallowed by the parser inside interpolations that are inside a string

2017-08-11 Thread ddekany

Bug fixed (FREEMARKER-70): The usage of loop variable built-ins, like 
loopVar?index, was disallowed by the parser inside interpolations that are 
inside a string literal expression (as in <#list 1..3 as 
loopVar>${'${loopVar?index}'}), saying that there's no loop variable in 
scope with loopVar name.


Project: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/incubator-freemarker/commit/056bf1cd
Tree: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/tree/056bf1cd
Diff: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/diff/056bf1cd

Branch: refs/heads/2.3-gae
Commit: 056bf1cd7e59740af304b2566caacd921378a5bd
Parents: 924a420
Author: ddekany 
Authored: Sat Aug 12 00:20:32 2017 +0200
Committer: ddekany 
Committed: Sat Aug 12 00:20:32 2017 +0200

--
 src/main/java/freemarker/core/StringLiteral.java | 12 +---
 src/main/javacc/FTL.jj   | 19 +--
 src/manual/en_US/book.xml| 13 +
 .../java/freemarker/core/ListErrorsTest.java |  5 +
 4 files changed, 36 insertions(+), 13 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/incubator-freemarker/blob/056bf1cd/src/main/java/freemarker/core/StringLiteral.java
--
diff --git a/src/main/java/freemarker/core/StringLiteral.java 
b/src/main/java/freemarker/core/StringLiteral.java
index c2b69a6..7c25623 100644
--- a/src/main/java/freemarker/core/StringLiteral.java
+++ b/src/main/java/freemarker/core/StringLiteral.java
@@ -41,15 +41,13 @@ final class StringLiteral extends Expression implements 
TemplateScalarModel {
 }
 
 /**
- * @param parentTkMan
- *The token source of the template that contains this string 
literal. As of this writing, we only need
- *this to share the {@code namingConvetion} with that.
+ * @param parentParser
+ *The parser of the template that contains this string literal.
  */
-void parseValue(FMParserTokenManager parentTkMan, OutputFormat 
outputFormat) throws ParseException {
+void parseValue(FMParser parentParser, OutputFormat outputFormat) throws 
ParseException {
 // The way this works is incorrect (the literal should be parsed 
without un-escaping),
 // but we can't fix this backward compatibly.
 if (value.length() > 3 && (value.indexOf("${") >= 0 || 
value.indexOf("#{") >= 0)) {
-
 Template parentTemplate = getTemplate();
 ParserConfiguration pcfg = parentTemplate.getParserConfiguration();
 
@@ -65,12 +63,12 @@ final class StringLiteral extends Expression implements 
TemplateScalarModel {
 
 FMParser parser = new FMParser(parentTemplate, false, tkMan, 
pcfg);
 // We continue from the parent parser's current state:
-parser.setupStringLiteralMode(parentTkMan, outputFormat);
+parser.setupStringLiteralMode(parentParser, outputFormat);
 try {
 dynamicValue = parser.StaticTextAndInterpolations();
 } finally {
 // The parent parser continues from this parser's current 
state:
-parser.tearDownStringLiteralMode(parentTkMan);
+parser.tearDownStringLiteralMode(parentParser);
 }
 } catch (ParseException e) {
 e.setTemplateName(parentTemplate.getSourceName());

http://git-wip-us.apache.org/repos/asf/incubator-freemarker/blob/056bf1cd/src/main/javacc/FTL.jj
--
diff --git a/src/main/javacc/FTL.jj b/src/main/javacc/FTL.jj
index 175614c..2963a41 100644
--- a/src/main/javacc/FTL.jj
+++ b/src/main/javacc/FTL.jj
@@ -78,7 +78,7 @@ public class FMParser {
 private ParserConfiguration pCfg;
 
 /** Keeps track of #list and #foreach nesting. */
-private List/**/ iteratorBlockContexts;
+private List iteratorBlockContexts;
 
 /**
  * Keeps track of the nesting depth of directives that support #break.
@@ -273,7 +273,9 @@ public class FMParser {
 }
 }
 
-void setupStringLiteralMode(FMParserTokenManager parentTokenSource, 
OutputFormat outputFormat) {
+void setupStringLiteralMode(FMParser parentParser, OutputFormat 
outputFormat) {
+FMParserTokenManager parentTokenSource = parentParser.token_source;
+ 
 token_source.initialNamingConvention = 
parentTokenSource.initialNamingConvention;
 token_source.namingConvention = parentTokenSource.namingConvention;
 token_source.namingConventionEstabilisher =

[1/3] incubator-freemarker git commit: Minor error message generation fix.

2017-08-11 Thread ddekany

Repository: incubator-freemarker
Updated Branches:
  refs/heads/2.3-gae f1f8080b4 -> 056bf1cd7


Minor error message generation fix.


Project: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/incubator-freemarker/commit/cdd12d8b
Tree: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/tree/cdd12d8b
Diff: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/diff/cdd12d8b

Branch: refs/heads/2.3-gae
Commit: cdd12d8be3a4b016d8564f7d7feadbb28c3cfa23
Parents: f1f8080
Author: ddekany 
Authored: Fri Aug 11 23:46:03 2017 +0200
Committer: ddekany 
Committed: Fri Aug 11 23:46:03 2017 +0200

--
 src/main/java/freemarker/core/UnexpectedTypeException.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/incubator-freemarker/blob/cdd12d8b/src/main/java/freemarker/core/UnexpectedTypeException.java
--
diff --git a/src/main/java/freemarker/core/UnexpectedTypeException.java 
b/src/main/java/freemarker/core/UnexpectedTypeException.java
index 73420e3..0878f81 100644
--- a/src/main/java/freemarker/core/UnexpectedTypeException.java
+++ b/src/main/java/freemarker/core/UnexpectedTypeException.java
@@ -104,7 +104,7 @@ public class UnexpectedTypeException extends 
TemplateException {
 new 
_DelayedJQuote(blamedAssignmentTargetVarName) }), 
 " has evaluated to ",
 new _DelayedAOrAn(new _DelayedFTLTypeDescription(model)),
-(blamedAssignmentTargetVarName == null ? ":" : ".")};
+(blamed != null ? ":" : ".")};
 }
 
 }

[2/3] incubator-freemarker git commit: (Minor code cleanup)

2017-08-11 Thread ddekany

(Minor code cleanup)


Project: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/repo
Commit: 
http://git-wip-us.apache.org/repos/asf/incubator-freemarker/commit/924a4201
Tree: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/tree/924a4201
Diff: http://git-wip-us.apache.org/repos/asf/incubator-freemarker/diff/924a4201

Branch: refs/heads/2.3-gae
Commit: 924a420119b72f663769d7f3e9422ba22637478f
Parents: cdd12d8
Author: ddekany 
Authored: Fri Aug 11 23:46:17 2017 +0200
Committer: ddekany 
Committed: Fri Aug 11 23:46:17 2017 +0200

--
 src/main/java/freemarker/template/utility/Constants.java | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/incubator-freemarker/blob/924a4201/src/main/java/freemarker/template/utility/Constants.java
--
diff --git a/src/main/java/freemarker/template/utility/Constants.java 
b/src/main/java/freemarker/template/utility/Constants.java
index fd48e70..ef8333d 100644
--- a/src/main/java/freemarker/template/utility/Constants.java
+++ b/src/main/java/freemarker/template/utility/Constants.java
@@ -96,7 +96,7 @@ public class Constants {
 
 }
 
-public static final TemplateHashModelEx EMPTY_HASH = new EmptyHashModel();
+public static final TemplateHashModelEx2 EMPTY_HASH = new EmptyHashModel();
 
 /**
  * An empty hash. Since 2.3.27, it implements {@link 
TemplateHashModelEx2}, before that it was only
@@ -133,12 +133,9 @@ public class Constants {
 /**
  * @since 2.3.27
  */
-public static final KeyValuePairIterator EMPTY_KEY_VALUE_PAIR_ITERATOR = 
EmptyKeyValuePairIterator.INSTANCE;
+public static final KeyValuePairIterator EMPTY_KEY_VALUE_PAIR_ITERATOR = 
new EmptyKeyValuePairIterator();
 
 private static class EmptyKeyValuePairIterator implements 
TemplateHashModelEx2.KeyValuePairIterator {
-
-static final EmptyKeyValuePairIterator INSTANCE = new 
EmptyKeyValuePairIterator();
-
 private EmptyKeyValuePairIterator() {
 //
 }

[jira] [Comment Edited] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124123#comment-16124123
 ] 

Daniel Dekany edited comment on FREEMARKER-70 at 8/11/17 9:36 PM:
--

The problem is not with macros, but with interpolations inside strings, which 
you happen to use in that macro call. But something like this on the top-level 
will fail too:

{code}
<#list 1..2 as loopvar>${"${loopvar?index}"}
{code}

while if you call the macro like this, it will work:

{code}
<@button caption=loopvar?index?string />
{code}

So the bug that will have to be fixed here is that because the string itself is 
a like a small template that's parsed separately, it doesn't inherit the loop 
variable stack from the enclosing parser.



was (Author: ddekany):
The problem is not with macros, but with interpolations inside strings, which 
you happen to use in that macro call. But something like this on the top-level 
will fail too:

{code}
<#list 1..2 as loopvar>${"${loopvar?index}"}
{code}

The problem that will have to be fixed here is that the string itself is a like 
a small template that's parse separately, and it doesn't inherit the loop 
variable stack from the enclosing parser...

> Loop Variables Not Resolving when used as marco arguments
> -
>
> Key: FREEMARKER-70
> URL: https://issues.apache.org/jira/browse/FREEMARKER-70
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.26-incubating
>Reporter: Bill Parkinson
>
> When invoking a macro inside of a #list  the loop variable is not in scope to 
> be used resolving the argument values to the macro call.
> Example
> {code:java}
> <#macro button caption>
> content irrelevant.
> 
> <#list ["a","b","c"]>
> <#items as loopvar>
> ${loopvar?counter} -- works
> ${loopvar?index} -- works
>  -- works
> <@button caption="${loopvar?index}" /> -- FAILS
> 
> 
> {code}
> The @button macro call fails with the message:
> The left hand operand of ?index must be a loop variable, but there's no loop 
> variable in scope with this name: loopvar
> Shouldn't loopvar be in scope for evaluating those macro argument values?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used in string interpolations

2017-08-11 Thread Daniel Dekany (JIRA)


 [ 
https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Dekany updated FREEMARKER-70:

Summary: Loop Variables Not Resolving when used in string interpolations  
(was: Loop Variables Not Resolving when used as marco arguments)

> Loop Variables Not Resolving when used in string interpolations
> ---
>
> Key: FREEMARKER-70
> URL: https://issues.apache.org/jira/browse/FREEMARKER-70
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.26-incubating
>Reporter: Bill Parkinson
>
> When invoking a macro inside of a #list  the loop variable is not in scope to 
> be used resolving the argument values to the macro call.
> Example
> {code:java}
> <#macro button caption>
> content irrelevant.
> 
> <#list ["a","b","c"]>
> <#items as loopvar>
> ${loopvar?counter} -- works
> ${loopvar?index} -- works
>  -- works
> <@button caption="${loopvar?index}" /> -- FAILS
> 
> 
> {code}
> The @button macro call fails with the message:
> The left hand operand of ?index must be a loop variable, but there's no loop 
> variable in scope with this name: loopvar
> Shouldn't loopvar be in scope for evaluating those macro argument values?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

2017-08-11 Thread Daniel Dekany (JIRA)


[ 
https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124123#comment-16124123
 ] 

Daniel Dekany commented on FREEMARKER-70:
-

The problem is not with macros, but with interpolations inside strings, which 
you happen to use in that macro call. But something like this on the top-level 
will fail too:

{code}
<#list 1..2 as loopvar>${"${loopvar?index}"}
{code}

The problem that will have to be fixed here is that the string itself is a like 
a small template that's parse separately, and it doesn't inherit the loop 
variable stack from the enclosing parser...

> Loop Variables Not Resolving when used as marco arguments
> -
>
> Key: FREEMARKER-70
> URL: https://issues.apache.org/jira/browse/FREEMARKER-70
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.26-incubating
>Reporter: Bill Parkinson
>
> When invoking a macro inside of a #list  the loop variable is not in scope to 
> be used resolving the argument values to the macro call.
> Example
> {code:java}
> <#macro button caption>
> content irrelevant.
> 
> <#list ["a","b","c"]>
> <#items as loopvar>
> ${loopvar?counter} -- works
> ${loopvar?index} -- works
>  -- works
> <@button caption="${loopvar?index}" /> -- FAILS
> 
> 
> {code}
> The @button macro call fails with the message:
> The left hand operand of ?index must be a loop variable, but there's no loop 
> variable in scope with this name: loopvar
> Shouldn't loopvar be in scope for evaluating those macro argument values?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (FREEMARKER-70) Loop Variables Not Resolving when used in string interpolations

2017-08-11 Thread Daniel Dekany (JIRA)


 [ 
https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Dekany resolved FREEMARKER-70.
-
   Resolution: Fixed
Fix Version/s: 2.3.27-incubating

Fix committed.

> Loop Variables Not Resolving when used in string interpolations
> ---
>
> Key: FREEMARKER-70
> URL: https://issues.apache.org/jira/browse/FREEMARKER-70
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.26-incubating
>Reporter: Bill Parkinson
> Fix For: 2.3.27-incubating
>
>
> When invoking a macro inside of a #list  the loop variable is not in scope to 
> be used resolving the argument values to the macro call.
> Example
> {code:java}
> <#macro button caption>
> content irrelevant.
> 
> <#list ["a","b","c"]>
> <#items as loopvar>
> ${loopvar?counter} -- works
> ${loopvar?index} -- works
>  -- works
> <@button caption="${loopvar?index}" /> -- FAILS
> 
> 
> {code}
> The @button macro call fails with the message:
> The left hand operand of ?index must be a loop variable, but there's no loop 
> variable in scope with this name: loopvar
> Shouldn't loopvar be in scope for evaluating those macro argument values?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

2017-08-11 Thread Bill Parkinson (JIRA)


 [ 
https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Parkinson updated FREEMARKER-70:
-
Description: 
When invoking a macro inside of a #list  the loop variable is not in scope to 
be used resolving the argument values to the macro call.

Example
{{
<#macro button caption>
content irrelevant.



<#list ["a","b","c"]>
<#items as loopvar>
${loopvar?counter} -- works
${loopvar?index} -- works
 -- works
<@button caption="${loopvar?index}" /> -- FAILS

}}

The @button macro call fails with the message:
The left hand operand of ?index must be a loop variable, but there's no loop 
variable in scope with this name: loopvar

Shouldn't loopvar be in scope for evaluating those macro argument values?



  was:
When invoking a macro inside of a #list  the loop variable is not in scope to 
be used resolving the argument values to the macro call.

Example

<#macro button caption>
content irrelevant.



<#list ["a","b","c"]>
<#items as loopvar>
${loopvar?counter} -- works
${loopvar?index} -- works
 -- works
<@button caption="${loopvar?index}" /> -- FAILS



The @button macro call fails with the message:
The left hand operand of ?index must be a loop variable, but there's no loop 
variable in scope with this name: loopvar

Shouldn't loopvar be in scope for evaluating those macro argument values?




> Loop Variables Not Resolving when used as marco arguments
> -
>
> Key: FREEMARKER-70
> URL: https://issues.apache.org/jira/browse/FREEMARKER-70
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.26-incubating
>Reporter: Bill Parkinson
>
> When invoking a macro inside of a #list  the loop variable is not in scope to 
> be used resolving the argument values to the macro call.
> Example
> {{
> <#macro button caption>
> content irrelevant.
> 
> <#list ["a","b","c"]>
> <#items as loopvar>
> ${loopvar?counter} -- works
> ${loopvar?index} -- works
>  -- works
> <@button caption="${loopvar?index}" /> -- FAILS
> 
> }}
> The @button macro call fails with the message:
> The left hand operand of ?index must be a loop variable, but there's no loop 
> variable in scope with this name: loopvar
> Shouldn't loopvar be in scope for evaluating those macro argument values?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

2017-08-11 Thread Bill Parkinson (JIRA)

Bill Parkinson created FREEMARKER-70:


 Summary: Loop Variables Not Resolving when used as marco arguments
 Key: FREEMARKER-70
 URL: https://issues.apache.org/jira/browse/FREEMARKER-70
 Project: Apache Freemarker
  Issue Type: Bug
  Components: engine
Affects Versions: 2.3.26-incubating
Reporter: Bill Parkinson


When invoking a macro inside of a #list  the loop variable is not in scope to 
be used resolving the argument values to the macro call.

Example

<#macro button caption>
content irrelevant.



<#list ["a","b","c"]>
<#items as loopvar>
${loopvar?counter} -- works
${loopvar?index} -- works
 -- works
<@button caption="${loopvar?index}" /> -- FAILS



The @button macro call fails with the message:
The left hand operand of ?index must be a loop variable, but there's no loop 
variable in scope with this name: loopvar

Shouldn't loopvar be in scope for evaluating those macro argument values?





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

2017-08-11 Thread Bill Parkinson (JIRA)


 [ 
https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Parkinson updated FREEMARKER-70:
-
Description: 


When invoking a macro inside of a #list  the loop variable is not in scope to 
be used resolving the argument values to the macro call.

Example
{code:java}

<#macro button caption>
content irrelevant.



<#list ["a","b","c"]>
<#items as loopvar>
${loopvar?counter} -- works
${loopvar?index} -- works
 -- works
<@button caption="${loopvar?index}" /> -- FAILS



{code}

The @button macro call fails with the message:
The left hand operand of ?index must be a loop variable, but there's no loop 
variable in scope with this name: loopvar

Shouldn't loopvar be in scope for evaluating those macro argument values?



  was:
When invoking a macro inside of a #list  the loop variable is not in scope to 
be used resolving the argument values to the macro call.

Example
{{

<#macro button caption>
content irrelevant.



<#list ["a","b","c"]>
<#items as loopvar>
${loopvar?counter} -- works
${loopvar?index} -- works
 -- works
<@button caption="${loopvar?index}" /> -- FAILS



}}

The @button macro call fails with the message:
The left hand operand of ?index must be a loop variable, but there's no loop 
variable in scope with this name: loopvar

Shouldn't loopvar be in scope for evaluating those macro argument values?




> Loop Variables Not Resolving when used as marco arguments
> -
>
> Key: FREEMARKER-70
> URL: https://issues.apache.org/jira/browse/FREEMARKER-70
> Project: Apache Freemarker
>  Issue Type: Bug
>  Components: engine
>Affects Versions: 2.3.26-incubating
>Reporter: Bill Parkinson
>
> When invoking a macro inside of a #list  the loop variable is not in scope to 
> be used resolving the argument values to the macro call.
> Example
> {code:java}
> <#macro button caption>
> content irrelevant.
> 
> <#list ["a","b","c"]>
> <#items as loopvar>
> ${loopvar?counter} -- works
> ${loopvar?index} -- works
>  -- works
> <@button caption="${loopvar?index}" /> -- FAILS
> 
> 
> {code}
> The @button macro call fails with the message:
> The left hand operand of ?index must be a loop variable, but there's no loop 
> variable in scope with this name: loopvar
> Shouldn't loopvar be in scope for evaluating those macro argument values?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (FREEMARKER-67) Doesn't support org.bson.Document's correct order of keys.

[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

[jira] [Commented] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

[jira] [Comment Edited] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes

[jira] [Updated] (FREEMARKER-68) Double-question mark operator does not properly test for Jython attributes

[jira] [Created] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

[jira] [Comment Edited] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

[jira] [Comment Edited] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

[jira] [Commented] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

[jira] [Resolved] (FREEMARKER-69) Chinese：自定义Directive与Variable变量名称一致导致FTL解析BUG，English:A bug when The user-defined directive key same as Variable key

[3/3] incubator-freemarker git commit: Bug fixed (FREEMARKER-70): The usage of loop variable built-ins, like loopVar?index, was disallowed by the parser inside interpolations that are inside a string

[1/3] incubator-freemarker git commit: Minor error message generation fix.

[2/3] incubator-freemarker git commit: (Minor code cleanup)

[jira] [Comment Edited] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

[jira] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used in string interpolations

[jira] [Commented] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

[jira] [Resolved] (FREEMARKER-70) Loop Variables Not Resolving when used in string interpolations

[jira] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

[jira] [Created] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

[jira] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments

22 matches

Site Navigation

Mail list logo

Footer information