Result: error:
AssertionError: Failure: Bad value body { color: blue; } for |filterCssValue
at new goog.asserts.AssertionError (/Users/nick/git/soynode/node_modules/obvious-closure-library/closure/goog/asserts/asserts.js:62:20)
at Object.goog.asserts.fail (/Users/nick/git/soynode/node_modules/obvious-closure-library/closure/goog/asserts/asserts.js:176:32)
at Object.soy.esc.$$filterCssValueHelper (/Users/nick/git/soynode/node_modules/closure-templates/soyutils_usegoog.js:2256:18)
at Object.soy.$$filterCssValue (/Users/nick/git/soynode/node_modules/closure-templates/soyutils_usegoog.js:1495:18)
com.google.template.soy.parsepasses.contextautoesc.SoyAutoescapeException: In file postHtml.soy:8, template views.postHtml.x: Error while re-contextualizing template views.postHtml.url in context (Context URI NORMAL URI SINGLE_QUOTE START):
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.SoyAutoescapeException.createCausedWithoutMetaInfo(SoyAutoescapeException.java:58)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.SoyAutoescapeException.createCausedWithNode(SoyAutoescapeException.java:93)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.contextualizeCallee(InferenceEngine.java:633)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.inferCallSite(InferenceEngine.java:601)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.visitCallNode(InferenceEngine.java:245)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitCallBasicNode(AbstractSoyNodeVisitor.java:304)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:110)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:56)
[template-compiler] at com.google.template.soy.basetree.AbstractNodeVisitor.visitChildren(AbstractNodeVisitor.java:59)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitChildren(AbstractSoyNodeVisitor.java:129)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.visitTemplateNode(InferenceEngine.java:201)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitTemplateBasicNode(AbstractSoyNodeVisitor.java:160)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:66)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.exec(InferenceEngine.java:174)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine.infer(InferenceEngine.java:149)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine.inferTemplateEndContext(InferenceEngine.java:106)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.ContextualAutoescaper.rewrite(ContextualAutoescaper.java:163)
[template-compiler] at com.google.template.soy.SoyFileSet.doContextualEscaping(SoyFileSet.java:1008)
[template-compiler] at com.google.template.soy.SoyFileSet.runMiddleendPasses(SoyFileSet.java:990)
[template-compiler] at com.google.template.soy.SoyFileSet.compileToJsSrcFiles(SoyFileSet.java:924)
[template-compiler] at com.google.template.soy.SoyToJsSrcCompiler.execMain(SoyToJsSrcCompiler.java:303)
[template-compiler] at com.google.template.soy.SoyToJsSrcCompiler.main(SoyToJsSrcCompiler.java:243)
[template-compiler] Caused by: com.google.template.soy.parsepasses.contextautoesc.SoyAutoescapeException: In file postHtml.soy:17, template views.postHtml.url__C33f6: Cannot determine which part of the URL {$path} is in.
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.SoyAutoescapeException.createWithoutMetaInfo(SoyAutoescapeException.java:42)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.SoyAutoescapeException.createWithNode(SoyAutoescapeException.java:76)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine.getContextAfterEscaping(InferenceEngine.java:862)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine.access$700(InferenceEngine.java:79)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.visitPrintNode(InferenceEngine.java:480)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:87)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:56)
[template-compiler] at com.google.template.soy.basetree.AbstractNodeVisitor.visitChildren(AbstractNodeVisitor.java:59)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitChildren(AbstractSoyNodeVisitor.java:129)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.visitTemplateNode(InferenceEngine.java:201)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitTemplateBasicNode(AbstractSoyNodeVisitor.java:160)
[template-compiler] at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:66)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.exec(InferenceEngine.java:174)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine.infer(InferenceEngine.java:149)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine.inferTemplateEndContext(InferenceEngine.java:106)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.hypothesizeContextualization(InferenceEngine.java:712)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.determineContextualization(InferenceEngine.java:662)
[template-compiler] at com.google.template.soy.parsepasses.contextautoesc.InferenceEngine$ContextPropagatingVisitor.contextualizeCallee(InferenceEngine.java:630)
[template-compiler] ... 19 more
This is using Closure templates release 2014-04-22.
From what I've gathered, there is no easy way to specify type aliases or custom types (especially if you want server- and client-side rendering). We've been using records in our templates, but that leaves us with large amounts of repeated param definitions (that are also responsible for the majority of a template's code). For example:
After cloning the HEAD of the repo, I cannot build the generated-soyutils target. It errors out with taskdef class com.google.template.soy.shared.internal.GenerateSoyUtilsEscapingDirectiveCode cannot be found.
$ ant generated-soyutils
Buildfile: /path/lib/closure-templates/build.xml
compile:
generated-soyutils:
BUILD FAILED
/path/lib/closure-templates/build.xml:99: taskdef class com.google.template.soy.shared.internal.GenerateSoyUtilsEscapingDirectiveCode cannot be found
using the classloader AntClassLoader[/path/lib/closure-templates/java/lib/aopalliance.jar:/path/lib/closure-templates/java/lib/args4j-2.0.17.jar:/path/lib/closure-templates/java/lib/cglib-nodep-2.2.2.jar:/path/lib/closure-templates/java/lib/easymock-3_0.jar:/path/lib/closure-templates/java/lib/guava-14.0.jar:/path/lib/closure-templates/java/lib/guice-3.0.jar:/path/lib/closure-templates/java/lib/guice-assistedinject-3.0.jar:/path/lib/closure-templates/java/lib/guice-multibindings-3.0.jar:/path/lib/closure-templates/java/lib/icu4j-51_1.jar:/path/lib/closure-templates/java/lib/javax.inject.jar:/path/lib/closure-templates/java/lib/jsr305.jar:/path/lib/closure-templates/java/lib/junit.jar:/path/lib/closure-templates/java/lib/objenesis-1_2.jar:/path/lib/closure-templates/java/lib/rhino-1.7_r2.jar:/path/lib/closure-templates/build/classes]
Closure templates cannot be used alongside other projects that use Google Guice and have upgraded to 4.0 due to breaking changes in the library. It would be nice if Closure Templates could release a new version compile against Guice 4.0.
It is understood that in order to use soy to JavaScript compilator one has to use soyutils.js, I created long time ago a bower component, which contains soyutils:
All would be good if it wasn't for release from 2014-04-22, which now requires goog library. Why has this been change? There are people outside of google who would like to use soyutils and render soy templates client side, who actually have no desire or need to use goog library and now there is a dependency on this? I understand that in google for most project if not all, goog is sort of prerequisite anyway but outside of google this may not be the case.
What we also established is that soyutils without goog + client side rendering works but one cannot use latest features: especially typed parameters.
My question therefore why is goog now a dependency for soyutils. We have a FE Engineer at work who tries now to create a minified soyutils bundle and now it weights about 150kb (soyutils + goog) minified.
Is it possible that in future version of soy this requirement will be dropped? 150 kb for us is not only problem from Site Speed point of view (performance) but more importantly because people still have EDGE and slower mobile connections for which they pay for ever MB to load websites.
It'd be good to have a native directive to format a timestamp, delegating to standard date formatting implementations such as SimpleDateFormat (Java) and Date.toLocaleDateString (JS). A possible interface could be:
We've been using the 2012 version of Closure Templates for years and we've recently been trying to upgrade to the latest version to take advantage of new features like static typing. Unfortunately, running the new version we get this error
SoyAutoescapeException: In file /home/chris/Programming/kinja-mantle/app/views/closure/tiger/messages.soy:454:81, template tiger.messages.tokenCallFailed: Messages are not supported in this context, because it would mean asking translators to write source code: (Context URI NORMAL URI DOUBLE_QUOTE START)
Would a patch that implements this with xliff 'g' elements be accepted? I know how to write an xliff export that works fine, and the exported templates already rely on Closure-specific 'x' placeholder handling.
This repo contains a lot of generated documentation (two sets of JavaDocs?) and code that is built from upstream. This stuff creates noise in the commit logs and causes churn when synchronizing from Google's internal sources. I also suspect they are rarely useful. Would anyone mind if we removed them?
{'12"45"'|truncate:6} is printed as 12&... because it acts on the expanded HTMl entities like " {'12"45"'|truncate:6|escapeHtml} forces ordering and is printed as 12"45" (the HTML source is 12"45")
I can't see the usefulness of acting on the escaped HTML and it causes artifacts (like ampersands) to appear in your output HTML, so the latter behavior seems more sane by default.
We're using Google Closure Templates on our website and we've run into an issue we just can't find a solution for.
We're setting up a sub template and we want to loop through an unknown amount of variables. We tried using nested loops but it's not working! Here's an example of the parameters sent to the SOY template below. We don't know how many sections will be provided. When trying to do a nested loop it simply doesn't work, it's only getting the first occurence:
When developing templates, it would be helpful to get the template, filename, line number, and error message for any compilation errors. That allows me to show the detailed error message along with the line of source code in context to the developer. I do that today by parsing the SoySyntaxException's message, after extracting the original exception from the suppressed frames. Luke suggested that this use case could be better supported.
closure-templates complains "SoySyntaxException: Found delegate template with same name blahblah but different param declarations"
I don't understand why this is a syntax error. The declarations are perfectly compatible with each other. Is there a good reason why I have to list the optional params of all the other deltemplates?
Reportedย byย dinoboff,ย Novย 8,ย 2009
It would be great to be able to compile Soy templates to Python.
Projectย Member ย #1ย kai.huang
Sorry, there are no current plans to add Python support.
Status:ย WontFixย
Labels:ย ยญTypeยญDefectย TypeยญEnhancementย #2ย dolapo
would you take outside contributions for this?
Projectย Member ย #3ย kai.huang
If you were to actually write a high quality backend implementation of Soy for Python,
with support for all the current features, then I'm sure we would be happy to add it to
the project. The main problem would be that going forward, we wouldn't have the
resources to maintain it when we add new features to the other backends, and it may even
break if we make certain large changes (probably not often though). But if you're
willing to maintain the Python backend when it gets broken or to implement key new
features, I'd say go for it!
PS. I'm going to be on leave for most of Q3, so it would be Q4 before it can be added to
the main project.
PPS. I think I recognize you as a Xoogler? Is that right? #4ย mark@testingยญsoftware.org
This is confusing to me. I could not find a Soy for Python. Is it that I looked at the
wrong places? Is dolapo or somebody else still working on a port?
Is there some research / dialog available on the benefits of having server side
templates in an Ajax application. I think mainly the data exchange will be XHR but I can
think of cases where a server side template could be helpful like creation of the
initial html page. #5ย [email protected]
I think there are some 3rd party Python implementations of Soy. Obviously, I can't vouch
for their accuracy in behavior and features.
I'll also keep an eye out for engineers inside Google who want to add a Python backend
to Soy. #6ย lalinsky
Wow, awesome! Thanks for this! This is actually something someone else was looking at
internally... I didn't catch a glimpse of this until now. I'm going to touch base with
the engineer who has been working on this.
One very unfortunate thing is that we been far too lazy in updating the open source
version of Soy, so it's likely there will be a large version gap; in the next version we
have much better support for strict autoescaping, for example. Once we get our open
source version up to date (I can't guarantee when that will be unfortunately) we can see
whether it is still convenient to patch, or whether the person working on it internally
is close enough to something workable that it makes sense just to finish that.
Thanks again! This is amazing!
We have several templates with an autoescape value set. Including any of these templates in a SoyFileSet causes all templates to fail with com.google.template.soy.tofu.SoyTofuException: Attempting to render undefined template.
When I try to compile the file with the rest of scripts of my application the compiler outputs this error:
client/vendor/closure-templates/soyutils_usegoog.js:1864: ERROR - Property runtimeType never defined on goog.debug
(goog.DEBUG ? (', but got ' + goog.debug.runtimeType(param)) : '') +
I am using goog.DEBUG=false in the compiler flags. I've tried to find the method in the Closure Library but I don't know where it's defined or why it's not found.
We use closure library and closure compiler, and we want to use closure templates.
But closure templates haven't got inheritance. That's really a problem for us.
As I understand, the reason why closure templates donโt have inheritance, is because templates must be simple, and easy to read.
But how can you live without inheritance in big projects?
For example, we have a template file button.soy that generates button with public template project.createButton and private templates: project.createOpenTag_, project.createCSSClasses_, project.createAttributes_, project.createContent_, project.createCloseTag_.
We have js class project.Button, and we have project.ButtonCircle (perhaps this separate class project.ButtonCircle seems unnecessary, but it's just an example) which extends project.Button. project.ButtonCircle needs little changes made in project.createButton template.
Of course we can add new functionality to project.createButton, but it's a very bad idea, because such approach will create monster templates in the future.
Or we can create public template project.createCircleButton in file button-circle.soy, call all private templates from project.createButton in it, and when we need to 'override' one of these private templates, (for example project.createCSSClasses_), we just create new private template in button-circle.soy with name project.createCSSClassesCirbleButton_.
Yet in this case we need to copy-paste all content from project.createButton to project.createCircleButton. That's terrible.
Also we tried using Delegate Templates, but it's not suited for inheritance.
But I cannot compile the .soy file using command line, I get this error:
java -jar SoyToJsSrcCompiler.jar --outputPathFormat cb.js --srcs cb.soy
Exception in thread "main" com.google.template.soy.base.SoySyntaxException: Found error where declared syntax version 2.0 is not satisfied: In file cb
.soy:2, template ns.templates.cb.cb: Tag {template .cb}: Template is missing SoyDoc.
at com.google.template.soy.base.SoySyntaxException.createWithoutMetaInfo(SoySyntaxException.java:52)
at com.google.template.soy.sharedpasses.ReportSyntaxVersionErrorsVisitor.exec(ReportSyntaxVersionErrorsVisitor.java:107)
at com.google.template.soy.soyparse.SoyFileSetParser.runSingleFileCheckingPasses(SoyFileSetParser.java:322)
at com.google.template.soy.soyparse.SoyFileSetParser.parseWithVersions(SoyFileSetParser.java:221)
at com.google.template.soy.soyparse.SoyFileSetParser.parse(SoyFileSetParser.java:173)
at com.google.template.soy.SoyFileSet.compileToJsSrcFiles(SoyFileSet.java:921)
at com.google.template.soy.SoyToJsSrcCompiler.execMain(SoyToJsSrcCompiler.java:303)
at com.google.template.soy.SoyToJsSrcCompiler.main(SoyToJsSrcCompiler.java:243)
I just started using the Python implementation for the first time today. Firstly - thanks!
As I always run my tests with DeprecationWarnings turned into errors I found that the __new__ method of class SanitizedContent (part of the python/sanitize.py file) passes arguments on to object.__new__(). This is deprecated in Python (since 2.6 I think) - http://bugs.python.org/issue1683368.
The change required is simple and causes no side effects:
python/sanitize.py
Change from:
class SanitizedContent(object):
content_kind = None
def __new__(cls, *args, **kwargs):
if cls is SanitizedContent or not cls.content_kind:
raise TypeError('SanitizedContent cannot be instantiated directly. '
'Instantiate a child class with a valid content_kind.')
return object.__new__(cls, *args, **kwargs)
To:
class SanitizedContent(object):
content_kind = None
def __new__(cls, *args, **kwargs):
if cls is SanitizedContent or not cls.content_kind:
raise TypeError('SanitizedContent cannot be instantiated directly. '
'Instantiate a child class with a valid content_kind.')
return object.__new__(cls)
The current artifacts on Maven central are old; 2015-04-10 and 2.5.0-SNAPSHOT. It would be great to get new versions published, because 2015-04-10 has some problems that are already fixed on master.
My preference would be for a named release, because I'd prefer not to depend on a SNAPSHOT version in production
Test output on Windows:
testGenerateExtractedMsgsFile(com.google.template.soy.xliffmsgplugin.XliffMsgPluginTest) Time elapsed: 0.011 sec <<< FAILURE!
junit.framework.ComparisonFailure: expected:<..." encoding="UTF-8"?>[
but was:<..." encoding="UTF-8"?>[
Moscow
Our secret location.
Camels
We really mean dromedary.
dromedary
Moose also says .
Tells what a moose says.
Cow says .
Tells what a cow says.
Camels
Ok, we mean camel here.
camel
]
Note:
The difference between the expected and result is the closing ']' at the end!
The current build breaks when mvn compile is run twice with no mvn clean between. I've not been able to figure out what is going wrong. I did find a hack that works where you add -proc:none to the javac compiler arguments and also add an old maven-processor-plugin to the pom, but that seems.. well, silly.
INTERNAL SOY ERROR.
Please open an issue at https://github.com/google/closure-templates/issues with this stack trace and repro steps
com.google.template.soy.base.SoySyntaxException: In file blocks/b-bouton/b-bouton.soy:19:5, template gorod.bBouton.Bo
utonTemplate.render: Invalid expression "$params.label2": Undefined field 'label2' for record type [label: string]
at com.google.template.soy.base.SoySyntaxException.createWithoutMetaInfo(SoySyntaxException.java:53)
at com.google.template.soy.soytree.SoySyntaxExceptionUtils.createWithNode(SoySyntaxExceptionUtils.java:47)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor$ResolveTypesExprVisitor.createException
ForInvalidExpr(ResolveExpressionTypesVisitor.java:890)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor$ResolveTypesExprVisitor.getFieldType(Re
solveExpressionTypesVisitor.java:780)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor$ResolveTypesExprVisitor.getFieldType(Re
solveExpressionTypesVisitor.java:802)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor$ResolveTypesExprVisitor.visitFieldAcces
sNode(ResolveExpressionTypesVisitor.java:461)
at com.google.template.soy.exprtree.AbstractExprNodeVisitor.visit(AbstractExprNodeVisitor.java:92)
at com.google.template.soy.exprtree.AbstractExprNodeVisitor.visit(AbstractExprNodeVisitor.java:70)
at com.google.template.soy.basetree.AbstractNodeVisitor.visitChildren(AbstractNodeVisitor.java:64)
at com.google.template.soy.exprtree.AbstractExprNodeVisitor.visitChildren(AbstractExprNodeVisitor.java:129)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor$ResolveTypesExprVisitor.visitExprRootNo
de(ResolveExpressionTypesVisitor.java:370)
at com.google.template.soy.exprtree.AbstractExprNodeVisitor.visit(AbstractExprNodeVisitor.java:80)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor$ResolveTypesExprVisitor.exec(ResolveExp
ressionTypesVisitor.java:362)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor.visitExpressions(ResolveExpressionTypes
Visitor.java:282)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor.visitSoyNode(ResolveExpressionTypesVisi
tor.java:270)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor.visitPrintNode(ResolveExpressionTypesVi
sitor.java:134)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:89)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:55)
at com.google.template.soy.basetree.AbstractNodeVisitor.visitChildren(AbstractNodeVisitor.java:64)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitChildren(AbstractSoyNodeVisitor.java:131)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor.visitSoyNode(ResolveExpressionTypesVisi
tor.java:274)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor.visitTemplateNode(ResolveExpressionType
sVisitor.java:130)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitTemplateBasicNode(AbstractSoyNodeVisitor.java:
162)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:68)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:55)
at com.google.template.soy.basetree.AbstractNodeVisitor.visitChildren(AbstractNodeVisitor.java:64)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitChildren(AbstractSoyNodeVisitor.java:131)
at com.google.template.soy.sharedpasses.ResolveExpressionTypesVisitor.visitSoyNode(ResolveExpressionTypesVisi
tor.java:274)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visitSoyFileNode(AbstractSoyNodeVisitor.java:158)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:66)
at com.google.template.soy.soytree.AbstractSoyNodeVisitor.visit(AbstractSoyNodeVisitor.java:55)
at com.google.template.soy.basetree.AbstractNodeVisitor.exec(AbstractNodeVisitor.java:45)
at com.google.template.soy.SoyFileSetParser.runSingleFileParsingPasses(SoyFileSetParser.java:265)
at com.google.template.soy.SoyFileSetParser.parseWithVersions(SoyFileSetParser.java:185)
at com.google.template.soy.SoyFileSetParser.parse(SoyFileSetParser.java:142)
at com.google.template.soy.SoyFileSet.compileToJsSrcFiles(SoyFileSet.java:965)
at com.google.template.soy.SoyToJsSrcCompiler.execMain(SoyToJsSrcCompiler.java:305)
at com.google.template.soy.SoyToJsSrcCompiler.access$100(SoyToJsSrcCompiler.java:41)
at com.google.template.soy.SoyToJsSrcCompiler$1.main(SoyToJsSrcCompiler.java:246)
at com.google.template.soy.MainClassUtils.runInternal(MainClassUtils.java:195)
at com.google.template.soy.MainClassUtils.run(MainClassUtils.java:187)
at com.google.template.soy.SoyToJsSrcCompiler.main(SoyToJsSrcCompiler.java:243)
--useCommonJsAsyncDef
usage = "When this option is used, each generated JS file with be wrapped with define() command and will specify external callees as dependencies according to the CommonJS asynchronous definition proposal. Use in conjunction with --dependencies"
When you need to pass the opt_data to goog.soy.renderXx() method for example from return value of an another method, you have to copy paste quite considerable type definition, if you want Closure Compiler to pass without errors on such code. The more parameters, the more copy pasting needed of course.
I had a short sweep through the code involved and I can come with PR if this is considered useful and acceptable. I guess some command line switch for this behaviour would be appropriate.
Soy currently compiles to JS globals, which is still a good "least common denominator" choice. Forward-looking projects are already using ES6 modules and transpiling it back to whatever format they like (AMD, CommonJS, globals, whatever). An option to compile to ES6 modules is a good current choice, and in the future will be a better default choice.
This is more of an annoyance than a problem; the corrupted terminal doesn't cause the tests to fail, and you can get back to a good state by typing reset. (It also doesn't affect Google internally.) But it would be nice to fix before we create a CI server for the project.
I'm against adding logic to Closure Templates to escape strings for terminal display, or adding a dependency on a library that has such logic. I think the easiest thing to do is just configure the tests to log at level SEVERE (since the corrupting log message is a WARNING). @tbroyer, @nathancomstock, WDYT?
given this template let statement inside a template
{let $BaseTimestamp : subtract($FromTimestamp, modulo($FromTimestamp, (1000 * 60 * 60 * 24))) /}
when extracting the source from a template in a custom visitor pass with toSourceString, the let statement is rewritten as
{let $BaseTimestamp : subtract($FromTimestamp, modulo($FromTimestamp, (1000 * 60 * 60 * 24)))}
which does not compile properly.
Similar to #30, it would be very nice for AMD users to have the option to compile modules to AMD so that a project's own dependency management system of choice can be used. (Where I work, we currently add an AMD wrapper around all Closure Templates-generated JS, but still have to manually ensure that any inner templates that get called are manually added as dependencies of the caller).
The .demoRawTextCommands and .demoDoubleBraces templates are failing when rendered in FeaturesUsage. The templates have ContentKind.TEXT but validation fails as the default template content type is ContentKind.HTML. The failure breaks the build.
This PR explicitly sets the expected content type to ContentKind.TEXT.
[INFO] --- exec-maven-plugin:1.3.2:java (java-features-example) @ soy ---
[WARNING] Warning: killAfter is now deprecated. Do you need it ? Please comment on MEXEC-6.
--------------------------------------------------------------------------------
[1. demoComments]
blah blah<br>http://www.google.com<br>
--------------------------------------------------------------------------------
[2. demoLineJoining]
First second.<br><i>First</i>second.<br>Firstsecond.<br><i>First</i> second.<br>Firstsecond.<br>
--------------------------------------------------------------------------------
[3. demoRawTextCommands]
[WARNING]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293)
at java.lang.Thread.run(Thread.java:724)
Caused by: com.google.template.soy.tofu.SoyTofuException: Expected template to be kind="html" but was kind="text": soy.examples.features.demoRawTextCommands
at com.google.template.soy.tofu.internal.BaseTofu$RendererImpl.enforceContentKind(BaseTofu.java:527)
at com.google.template.soy.tofu.internal.BaseTofu$RendererImpl.render(BaseTofu.java:499)
at com.google.template.soy.tofu.internal.BaseTofu$RendererImpl.render(BaseTofu.java:486)
at com.google.template.soy.examples.FeaturesUsage.execMain(FeaturesUsage.java:147)
at com.google.template.soy.examples.FeaturesUsage.main(FeaturesUsage.java:91)
... 6 more
I am fairly new to the library, but I am failing to compile it (trying to add some helpers).
My system is an OSX 10.9 and Java version is "1.8.0_25".
Simply running ant will generate the warning which aborts the build process. If I remove the -Werror switch in the build.xml file, the compilation finishes without problems.
It's my understanding that SoyToJsSrcCompiler.jar wants Java 1.7 (I had to upgrade my old Java 1.6 to be able to run it), but in the build.xml the target is 1.6 (which is probably what is generating this problem). It seems a bit confusing.
I am not sure, who has permissions to publish to maven repository for com.google.template but it would be nice to see latest released published there. I could help with that but I lack permissions.
$ java -jar target/soy-2.5.0-SNAPSHOT-SoyToJsSrcCompiler.jar --outputPathFormat simple.js --srcs hello.soy
INTERNAL SOY ERROR.
Please open an issue at https://github.com/google/closure-templates/issues with this stack trace and repro steps
java.lang.IllegalStateException: Casting long to integer results in overflow: 1000000000000
at com.google.common.base.Preconditions.checkState(Preconditions.java:200)
at com.google.template.soy.data.restricted.IntegerData.integerValue(IntegerData.java:130)
at com.google.template.soy.data.internalutils.InternalValueUtils.convertPrimitiveDataToExpr(InternalValueUtils.java:66)
at com.google.template.soy.sharedpasses.opti.SimplifyExprVisitor.attemptPreeval(SimplifyExprVisitor.java:231)
at com.google.template.soy.sharedpasses.opti.SimplifyExprVisitor.visitExprNode(SimplifyExprVisitor.java:204)
Reproduced with the compiler at head.
This is perfectly valid javascript because numbers are doubles? And in Java, it should convert to double or long?
Relatedly, it's not clear to me why the soy compiler is trying to evaluate the expression at all? This seems like something the Java or JS compiler would be more effective at.
When Closure Templates was maintained on Google Code, someone submitted a patch to allow building out JS as AMD modules: https://code.google.com/p/closure-templates/issues/detail?id=29 . This feature would be very useful for us at Gawker Media, so I was wondering whether outside contributions like this are being considered for inclusion now that the project has migrated?
I updated my plovr fork to use the latest closure-* repositories. However, I get the following warning from closure-templates:
Jul 02, 2014 1:18:50 PM com.google.template.soy.GuiceInitializer getHackySoyFileSetFactory
WARNING: Falling back to statically-injected SoyFileSetFactory; unpredictable behavior is likely. Instead of constructing a SoyFileSet.Builder directly, either inject it using Guice (with SoyModule installed), or call the static SoyFileSet.builder() method.
Maybe it's part of the hacky method name, but I just wanted to be sure.