Generate compiler-friendly template params

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Create template (test.html):
{namespace myNamespace}
/** @param myParam */
{template .test1}
Test1 {$myParam}
{/template}

2. Compile:
java -jar SoyToJsSrcCompiler.jar --codeStyle concat 
--shouldProvideRequireSoyNamespaces --outputPathFormat test.js test.html

What is the expected output? What do you see instead?
The resulting output is:
goog.provide('myNamespace');
goog.require('soy');
myNamespace.test1 = function(opt_data) {
  return 'Test1' + soy.$$escapeHtml(opt_data.myParam);
};

In order to support the Closure compiler variable renaming optimizations, I 
expect this:
goog.provide('myNamespace');
goog.require('soy');
myNamespace.test1 = function(opt_data) {
  return 'Test1' + soy.$$escapeHtml(opt_data["myParam"]);
};

Otherwise, myParam is renamed, and the compiled JavaScript breaks.

What version of the product are you using? On what operating system?
Latest
version 20100708 - Linux

Please provide any additional information below.
I would add an additional flag to generate this kind of code, or merge it with 
the flag that generates Closure compiler-friendly requires/provides.

Thanks!

Original issue reported on code.google.com by hugo.gfi...@gmail.com on 18 Jul 2010 at 8:58

[GoogleCodeExporter]

In case anyone is running into the same problem, I'm post-processing code with 
this command:
sed -e 's/opt_data\.\([a-zA-Z0-9]\+\)/opt_data["\1"]/g' test.js

Original comment by hugo.gfi...@gmail.com on 18 Jul 2010 at 9:26

[GoogleCodeExporter]

This is not a bug.  The Closure Templates compiler (Soy compiler) is working 
correctly.  Let me explain the cases below.

Case 1 (general answer):  In order to successfully use Closure Compiler with 
Closure Templates, you should be compiling ALL of your JavaScript code together 
with Closure Compiler -- this means both your hand-written JS code that calls 
the templates and the JS code generated by Closure Templates.  Then the name 
'myParam' will be renamed to the same short name in both your hand-written JS 
code and in the template JS code.  Does that make sense?

Case 2:  In the case where it's absolutely impossible for you to compile all 
your JS together using the Closure Compiler (e.g. if you're getting template 
data from the server so that your data keys cannot be processed by the Closure 
Compiler), you'll want to use bracket notation and string keys to access the 
data in your template code, which is perfectly valid syntax.  However, your 
template param names (the top level names in your template data) cannot be 
accessed using bracket notation and string keys.  Therefore, you'll need to 
wrap the json data with the un-renamed keys in another object before passing it 
to the template.  For example:

var jsonData = ...  // retrieve your JSON data from server
var templateData = {jsonData: jsonData};
var output = myNamespace.test1(templateData);

Here's what your template would look like:
{namespace myNamespace}
/** @param jsonData */
{template .test1}
Test1 {$jsonData['myParam']}
{/template}

Does that make sense?

Original comment by kai.hu...@gmail.com on 18 Jul 2010 at 11:35

[GoogleCodeExporter]

Yes, you nailed it! 

I am using both cases.

For case 1, although all the code was compiled together, some template calls 
were in the form:

myNamespace.test1({"myParam": "foo"})

rather than:

myNamespace.test1({myParam: "foo"})

so just making sure I allowed the closure compiler to do the renaming of all 
instances of myParam solved the issue (rather than forcing the compiler not to 
rename any instance of myParam).

Case 2: I was not aware of this json wrapping technique / notation. Thanks for 
sharing, I'll use it!

Thanks for your time Kai!!

Original comment by hugo.gfi...@gmail.com on 19 Jul 2010 at 2:45

[GoogleCodeExporter]

No problem.  Now you understand some of the tricks in using Closure Compiler 
and Closure Templates together.

Original comment by kai.hu...@gmail.com on 19 Jul 2010 at 7:46

• Changed state: Done
• Added labels: Type-Other
• Removed labels: Type-Defect