Groovy Template quote escape problem

patch diff to be applied from groovy/groovy-core

Thomas: I'm not clear on the purpose of that test – that GString expression will be expanded during initial parsing (and will fail, due to the first backslash). Is that what you wanted? If not, you need to escape it:
String source = "\"this\" is tricky: \$

";

If you have a Groovy Template (from groovy.text.SimpleTemplateEngine) which contains (in a File for example)

"this" is tricky: $

");

which is not a valid groovy statement (as of now). I think it should be but a GString is expected to be a plain groovy statement so

out.print("\"this\" is tricky: $

");

would be correct. I think the lexer needs to handle that since the first statement is correct java while the second is not.

> I think the lexer needs to handle that since the first statement is correct java while the second is not.

Yes, because regular Java doesn't do GStrings.... In order for GString expressions to be truly useful, they have to host real Groovy code, like closures, possibly with nesting strings, possibly with nested GString expressions. How do you handle backslashes in nested GStrings? The answer is not to try. I think the handling currently in place is the correct thing to do. Double quotes delimit a nested language.

So can I assume that the intention of the attached test is to break the build?

Its not intended to break the build, its intended to show a bug.

I'm quite sure that you will see something like that in templates and either the lexer or the groovy template engine need to handle this case.

I inlined the template text in this testcase to not depend on external files etc. But you are welcome to move the example

$

into a file and let it run from there.

I know that

$

is a better solution. But since GStrings are plain groovy statements its perfectly fine the run the "broken" example.

Agreed. The SimpleTemplateEngine needs to be fixed.

Sam, it looks like a problem for you.

A little more obvious problem:

$

won't work when used inside templates.

I have implemented a solution to this problem. The solution uses a cascading translator that converts

$

to

<?= hello + " " + hello ?>

and finally, to

out.println( hello + " " + hello );

which is a valid Groovy statement. I would like to contribute and/or maintain this code for Groovy.

Niall, attach your patch to one of the issues, and we'll have a look at it.

The attached file is not exactly a patch but rather a rework of the parsing done for the templates. If it is reasonable at this stage to port the GStringTemplateEngine and SimpleTemplateEngine to this framework then I would be happy to do it.

Attached you will find some test drivers and an example template with some "tricky" expressions. Don't know what licence to attach to these?

Whoops! in haste I did not attach a parser for the closure used by the GStringTemplateEngine. I have attached it on this upload. It produces an identical script to the one produced by the current GStringTemplateEngine, except it does not escape quotes within $

expressions. The following will generate the Groovy script from a template.

java TestCascade template.groovy

Oh Template and Groovlet master!!!

Looking at http://jira.codehaus.org/browse/GROOVY-399 - we should write the test cases asap - before refactoring the whole parser stuff. After a first glimpse, it could help with all those char-by-char parser short-comings.

OK, I made a few changes to the existing code base so that the ugly problems with quotes inside (for now simple) GStrings goes away. Not as good as the other proposals listed here for a re-write but at least gets rid of the ugly cases for now.

I also tried grafting in the current antlr GString parsing into the template codebase and made some progress but backed out as it was going to take a lot more time to finish than I have right now.