[jira] [Resolved] (FREEMARKER-70) Loop Variables Not Resolving when used in string interpolations
[ 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)
[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
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 = parentTokenSource.namingConventionEstabilisher; @@ -285,9 +287,14 @@ public cl
[1/3] incubator-freemarker git commit: Minor error message generation fix.
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)
(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] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used in string interpolations
[ 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] [Comment Edited] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments
[ https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments
[ https://issues.apache.org/jira/browse/FREEMARKER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments
[ 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] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments
[ 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] [Updated] (FREEMARKER-70) Loop Variables Not Resolving when used as marco arguments
[ 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
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] [Comment Edited] (FREEMARKER-69) Chinese:自定义Directive与Variable变量名称一致导致FTL解析BUG,English:A bug when The user-defined directive key same as Variable key
[ https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Resolved] (FREEMARKER-69) Chinese:自定义Directive与Variable变量名称一致导致FTL解析BUG,English:A bug when The user-defined directive key same as Variable key
[ 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)
[jira] [Comment Edited] (FREEMARKER-69) Chinese:自定义Directive与Variable变量名称一致导致FTL解析BUG,English:A bug when The user-defined directive key same as Variable key
[ https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (FREEMARKER-69) Chinese:自定义Directive与Variable变量名称一致导致FTL解析BUG,English:A bug when The user-defined directive key same as Variable key
[ https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (FREEMARKER-69) Chinese:自定义Directive与Variable变量名称一致导致FTL解析BUG,English:A bug when The user-defined directive key same as Variable key
[ https://issues.apache.org/jira/browse/FREEMARKER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Created] (FREEMARKER-69) Chinese:自定义Directive与Variable变量名称一致导致FTL解析BUG,English:A bug when The user-defined directive key same as Variable key
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] [Updated] (FREEMARKER-68) Double-question mark operator does not properly test for Jython attributes
[ 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] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes
[ https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 org.python.core.PyObject.__f
[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes
[ https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 org.python.core.P
[jira] [Comment Edited] (FREEMARKER-68) Double-question mark operator does not properly test for attributes
[ https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 org.python.core.PyObject.__findit
[jira] [Commented] (FREEMARKER-68) Double-question mark operator does not properly test for attributes
[ https://issues.apache.org/jira/browse/FREEMARKER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (FREEMARKER-67) Doesn't support org.bson.Document's correct order of keys.
[ 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)