We Keep Coding

WebStorm do not inspect part of underscore template

I have the following template in bootstrap.js file:
As you can see, WebStorm shows errors because it can't parse the source correctly.
I'm wondering if there is any way:
to completely disable inspection on that particular region in the file
wrap it in the comments and specify for the template engine to remove these comments when rendering template.

WebStorm provides no support for UnderscoreJS (WEB-679). But, as the syntax looks similar to EJS, you can try the following:
associate the .js files with embedded template syntax with EJS file type, by adding <file_name>.js as a pattern there
when associating, choose 'javascript' as template data language for these files

Using handlebars runtime library

Can somebody help me with a sample code on how to use the handlebars runtime library (handlebars.runtime.js) please?
I have tried to use Handlebars.compile, which obviously does not work, because I know runtime library is to avoid compiling templates.
Also I have tried to use Handlebars.template method by passing the template as a string, but it is not working as the template method expects a function as a parameter.
I think I am doing something basically wrong. Are there any documentations on how to use runtime library on its own?
Much appreciate the help.
More details:
I first used handlebars.js file, which was working good, but my team-mate noticed the compressed file is too big (>40KB) for our purpose (just a few templates in our site).
So, I tried using just handlebars.runtime.js file. Is this correct, or am I missing something?
Here is the sample I have tried: http://jsfiddle.net/2KfsM/
<div id="container"></div>
<script id="hb-example" type="text/handlebars-template">
<p>{{sampleText}}</p>
</script>
The js piece:
var template = Handlebars.compile($('#hb-example').html());
$('#container').html(template({sampleText: 'Here is a sample'}));

You can really improve performance by precompiling your template. But, in order to use the handlebar runtime library you have to first compile your existing template.
There is no Handlebars.compile function available in the runtime library.
Here is some links:
http://handlebarsjs.com/precompilation.html
http://berzniz.com/post/24743062344/handling-handlebars-js-like-a-pro

Eclipse code fomatting

I have some twig files that are a mixture of JavaScript, HTML, and twig markup. Is there a way with Eclipse to hi-lite a section of code and format it as, say JavaScript, then hi-lite another section and format it as HTML? I tried association the file type *.twig with the JavaScript editor, but, I do not seem to get any formatting. Syntax highlighting and code completion would be good too.
Thanks,
Scott

It is possible. If you have HTML/JS editors available (eclipse classic has them by default).
Go to preferences and: General > Editors > File Associations and add *.twig as a new file type and then add HTML editor (in the bottom panel) to it.
Then go to: General > Content Types, click on Text/HTML node (in Content Types box) and add *.twig file association in the bottom panel.
I've checked this and it works.

You can try to find a plugin that will support twig files and provide syntax highlighting. The Twig Eclipse Plugin looks promising as it at least seems to support HTML and twig markup together.

jquery/javascript in rails 3

I was under the impression that you could put javascript in a view template in Rails 3. For example, if I had this html in views/public/home.html.erb
<div id="block">click</div>
then in views/public/home.js.erb, I thought I could put the following javascript, and then click on html to trigger the javascript. However, when I tested it, I got no results. But if I put the javascript in assets/javascript/application.js, then everything worked fine...Shouldn't it also work if it was in a js template with the same name as the html view?
$(document).ready(function(){
test();
});
function test() {
$("#block").click(function() {
$('#block').hide();
});
}

Ummm. no. It just doesn't work that way. Only one of views/public/home.* will be rendered, depending on the responds type.

Javascript shouldn't be added as a view file (bla.js.erb). They must be put in assets/javascripts or at least in lib or vendor directory.
You must also require them in your application.js file, if you already don't use require_tree.
In this way you won't need to reference the javascript in any way in your view (the application.js will include it for you). Otherwise, you need to specify a layout to insert javascript files in block, because views are rendered after tag.
There are a lot of reason not to put javascript directly in html (except for tests obviusly), read the rails asset pipeline for more information.
When you create a view with a different extension from html.erb that will be used only if your url specify a format with that extension, for example mywebsite/users.json will return eventually a index.json.erb.
For AJAX you would like to return a JSON object, not javascript which is definitely not a correct approach. Remember that you are using a framework and you should follow it's guidelines. If you want to live it's rails, it will be hard to work with it.

You can use javascript_include_tag
If you have the js files source1.js, source2.js in public/javascript then you can include them using
javascript_include_tag 'source1', 'source2'

Executing groovy statements in JavaScript sources in Grails

There are essentially 2 places to define JavaScript functions in Grails, directly in a element on the GSP, and within a separate javascript source file under /web-app/js (for example, application.js). We have defined a commonly reused javascript function within application.js, but we also need to be able to generate parts of the function dynamically using groovy code. Unfortunately, ${some groovy code} does not appear to be processed within separate javascript source files.
Is the only way to do this by defining the javascript function within a script tag on a GSP page, or is there a more general solution? Obviously we could define the javascript function in a script tag within a template GSP file which would be reused, but there is a lot of push to keep our javascript functions defined all together in one place (i.e. the external javascript source file). This has performance benefits as well (the javascript source files are usually just downloaded once by each client's browser, instead of reloading the same javascript functions within the source of every html page they visit). I have toyed around with the idea of breaking the function up into static and dynamic pieces, putting the static ones in the external source and putting the dynamic ones in the template GSP, then gluing them together, but this seems like an unnecessary hack.
Any ideas?
(edit: It may sound like the idea of dynamically generating parts of a JavaScript function, which is then downloaded once and used over and over again by the client, would be a bad idea. However, the piece which is "dynamic" only changes perhaps once a week or month, and then only very slightly. Mostly we just want this piece generated off the database, even if only once, instead of hard coded.)

An easy solution to keep your JavaScript unobtrusive is to create a JavaScriptController and map its actions "/js/*" by adding this to your UrlMappings.groovy file:
"/js/$action"{
controller = "javascript"
}
then just create an action for each dynamic JS file you want, include in in your layout <HEAD>, and presto, you've got a JS file that you can insert Grails snippets into! :)
Note: I've found that there's currently a bug in Grails that doesn't map file extensions to content-types properly, so you'll need to include <%# page contentType="text/javascript; UTF-8" %> at the top of your view files.

This is a great solution. I would like to offer a suggestion to use somthing other then a mapping of "/js/$action" because this is no longer going to allow you to access you javascript files in /web-app/js/. All your javascript files would have to be moved to a the directory your controller would point to.
I would use something like
"/dynjs/$action"
This way you still can point to files in the /web-app/js/ files with out conflict and enjoy the benifits of gsp tags in javascript files
Please correct me if I'm wrong.

Or this... have a tag/service/dynamic method that lets tags write out their JS+CSS+whatever else, to a "cache" which is used to build the JS+CSS resources by a different controller.
Full concept here: [http://www.anyware.co.uk/2005/2009/01/19/an-idea-to-give-grails-tags-esp/][1]

If you want to use models created by the controller (that rendered HTML page which reference the Javascript in which you intend to use groovy code) in the Javascript code, then you can use this technique:
This technique does not need to change URL mappings and does not require you to create extra controller.
In your view GSP add javascript as follows:
<script type="text/javascript">
<g:render template="/javascript/yourJavascriptFile"/>
</script>
In views folder create a "javascript" folder. And create a file named:
_yourJavascriptFile.gsp
You can not only use all the GSP code in your _yourJavascriptFile.gsp file, but you can also use all the models created in your controller (that is rendering the view).
NOTE: There is nothing special about javascript folder. You can name it anything you want OR use an existing view folder. This is just a matter of organizing and identifying your HTML spitting GSP from Javascript spitting GSPs. Alternatively, you can use some naming conventions like: _something.js.gsp etc.

Name your scripts like this
/wherever/the/js/files/are/thescript.js.gsp
The gsp code inside will be rendered correctly by grails. This works, but I have no idea if it's considered a Good Idea or not.

There is another way - pass in the generated code into a function that expects closures. Those closures is generated by the program of course. The generated code is of course inlined/script-tagged in the gsp page.
it may or may not work depending on the nature of the code being generated. But i suspect it will work, and if it doesnt, minor tweaking to the coding style of your javascript will definitely make it work. Though, if these 'generated' code doesnt change much, this quite overkill imo.