Add support for escaping raw expressions (TVAR) #1085
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JonMcPherson
commented
Nov 29, 2023
| @@ -87,7 +87,7 @@ public void shouldCompileTo(final String template, final Object context, | |||
| throws IOException { | |||
| Template t = compile(template, helpers, partials); | |||
| String result = t.apply(configureContext(context)); | |||
| assertEquals("'" + expected + "' should === '" + result + "': " + message, expected, result); | |||
| assertEquals("'" + result + "' should === '" + expected + "': " + message, expected, result); | |||
There was a problem hiding this comment.
Minor fix to the order of arguments so that result should equal expected instead of the other way around
JonMcPherson
commented
Nov 29, 2023
|
|
||
| import static org.junit.Assert.assertEquals; | ||
|
|
||
| public class Issue1084 extends AbstractTest { |
There was a problem hiding this comment.
This is a copy of the Issue294 test suite except uses raw expressions (triple curly brackets)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes Issue #1084
Escaping raw expressions (TVAR) is supported by Handlebars.js, but Handlebars.java currently only supports escaping normal expressions (VAR). It is a simple fix to also support escaping raw expressions by updating
varEscapeto first check with the extra curly bracket in the delimiters likestart + "{"andend + "}", then otherwise check with the normal start and end delimiters like before. The visitEscape function doesn't need to change since the ignoring behavior is the same, we only care to drop the escape character.It would be great if this could be merged, and a new version cut and released as soon as possible. This is a big gap in this implementation, and we need it fixed ASAP. Much appreciated!
EDIT: I just noticed that the handlebars spec actually doesn't mention escaping raw expressions, or really much about escaping expressions in general, but I do see that the JS lexer/parser only cares if it starts with
\{{, and does not invalidate if it contains more{like the Java implemtation does. So it just works to escape\{{{raw}}}as well as\{{var}}. So I think this should still be merged to at least have parity with the JS implementation.Additionally, I found a workaround by just wrapping the normally escaped var with curly brackets like converting
{{{raw}}}to{/{{raw}}}which achieves the same result.See here: https://github.com/handlebars-lang/handlebars-parser/blob/master/src/handlebars.l#L46-L47