如何转义 node.js 中的 EJS 模板代码以在客户端进行评估？

Question

I use node.js/ejs on the server side and backbone.js on the client side. Both server side and client side use the same templating style. So the problem is, if I put template code meant for the client inside a template it still get's parsed on the server side.

If found out that something like this works:

<%- "<%= done ? 'done' : '' %\>" %>

However, IMHO this uglifies the code in a way which makes the whole point of using templates useless.

How would you approach this?

Is there a way to define blocks of code inside EJS-templates which do not get parsed like a {literal}-tag used in other templating languages?

Update: For now I use backbone's _.templateSettings to use different delimiters on the client side.

Update: Here's a similar solution in a JSP context: Underscore.js Templates Within JSP

Answer 1

The way I have dealt with this is to override the opening and closing tags on node so that the 2 instances of ejs are lookgin for different tags.

On node you can pass in options

{open:'<%',close:'%>'}

In my case I use <% and <@ for my two versions. Then in node ejs template I have something like this (where name is from backbone and everyauth obviously from node):

<% if(everyauth.loggedIn) %><h1><@= name @></h1><% } %>

Answer 2

I use backbone.layout.manager on both the client and server side, because I want my templates to be exactly the same.

The way I solved the template delimiter issue was to render the page on the server side, then inject the raw backbone templates.

Answer 3

With new ejs you can add a custom delimiter at client side :

https://github.com/mde/ejs#custom-delimiters

eg :

Custom delimiters can be applied on a per-template basis, or globally:

var ejs = require('ejs'),
    users = ['geddy', 'neil', 'alex'];

// Just one template
ejs.render('<?= users.join(" | "); ?>', {users: users}, {delimiter: '?'});
// => 'geddy | neil | alex'

// Or globally
ejs.delimiter = '$';
ejs.render('<$= users.join(" | "); $>', {users: users});
// => 'geddy | neil | alex'

Answer 4

I assume the question could be read as following because it was this thread Google provide me at first link:

“How I can escape EJS template code delimiter tag only for limited items?”

tl;dr:

Use <%# %> to break the original parsing code (eg <<%# %>%= done ? 'done' : '' %<%# %>> will done the following unparsed code <%= done ? 'done' : '' %> )

Long explanation

Imagine a case I decide to change % by ? using { delimiter: '?' } { delimiter: '?' } option (that could be the case here, because we want not to use the same has Backbone.js).

Great, that solves your problem. Imagine now later, for some reason, you use your templating system to generate an XML. This XML will start with <?xml version="1.0" encoding="UTF-8"?> .

You will facing the same issue again. What do? You will change the delimiter again? And after that, you will change again? etc. No, for punctual escaping, what we should is just to be capable to say “Not parse this part of the document as EJS”.

So a trick is to avoid EJS understand it's an EJS delimiter parser. So avoid it (in our current case) parse <? (or <% in an original case).

So by simply adding <?# ?> to break the parsing, you will add nothing (the # item is for EJS comment) and you will avoid parser to understand <<?# ?>?xml version="1.0" encoding="UTF-8"?<?# ?>> . The output will be <?xml version="1.0" encoding="UTF-8"?>

Conclusion

In a punctual necessity to avoid EJS parsing, you can just trick the parser to produce the output you need by using <%# %> as a delimiter tag breaker.

For sure, probably in your case, you can just use the marked answer because you will use the EJS tag in a lot of cases.

Answer 5

Well, the way that I currently approach this is to use require.js with the text plugin; this allows me to include the templates using AJAX during development time and have them all compiled into an optimized/minified single file bundle during deploy time.

Of course, if you don't use require.js for dependency management of the rest of your JS code this doesn't work nearly as well, but I can't stand to do javascript dev without require.js anymore now that I'm used to it anyway.

Alternately, there may be other similar technologies that you could use to solve the same problem.