Server side templates, client side templates - Automatic conversion?

Question

With the event of the jQuery templates plugin, I am wondering how to maintain both server-side and client-side templates.

Because in my case, I have some templates, that would be duplicates - server-side as well as client-side. Just imagine this:

You have a form, where you can enter list points. When you press submit, an AJAX request is generated but the entry is already showed on your page.

Now, the markup for this bullet point should be the same - wether it was generated through JS or by my PHP/.NET/whatsoever application.

Are there any good ways to maintain those templates / keep them in sync? Or do I really have to manually maintain both templates?

What is your experience in applications using JS templates?

Mordred

Great point you bring up, and I am surprised it is not spoken about more. I asked Phil Haack about this (haacked.com/archive/2010/11/09/… answer was confusing - Dave Ward also mentions the need for jquery tmpl view engine - encosia.com/2010/12/02/…. – Iaea

I just saw github.com/awhatley/jquery-tmpl.net and github.com/xyu/jquery-tmpl-php – Both try to port the jQuery tmpl engine to .NET / PHP. – Mordred

Added a interesting use case which may be useful for you someday. Good question we had to solve a couple of months ago. – Ormuz

Answer 1

If you like JS->PHP priority :) then you have this two jquery-tmpl compatible template renderer for PHP backend

1. https://github.com/abackstrom/jquery-tmpl-php
2. https://github.com/xyu/jquery-tmpl-php

If you prefer more PHP->JS priority :) then you can try this Javascript implementation of popular PHP templating Smarty

1. http://code.google.com/p/jsmart/

Or you can try something more neutral like:

1. Mustache http://mustache.github.com/

Hephzibah

Answer 2

My coworker is the author of the .NET parser you mention, so I've used it quite a bit to share templates between the client and server. To be clear - it's the same template, same file no matter whether it's being parsed on the client or server. So no duplication/maintenance headaches, which is very nice.

The only caveat we've run into is advanced logic. The data that the template renders needs to be more or less print-ready at the time of rendering. So checks for array lengths need to be booleans with the result, strings need to be pluralized, dates need to be formatted, etc. I believe Aaron is working on a way to pass functions in as named parameters to the .NET version, so that e.g. a pluralize function available in the scope of the template on the client-side could be replicated in C# and used in the same way on the server, allowing more logic and processing to happen within the template. Still, even having to pre-process the data, it's been incredibly useful.

Blanks

Answer 3

The Spark View Engine (.NET) has a javascript rendering functionnality: http://blog.robertgreyling.com/2009/11/teaching-javascript-how-to-render-your.html

Another way to have only one set of templates is to do only server side rendering, using ajax to get the updated html from the server.

Truffle

Answer 4

I usually store them on the view; here I'm going to tell you about a really interesting use-case I found for jquery-tmpl.

I've used jquery-tmpl on a site that, due to the huge amount of requests, required a technique I call decontextualization. This technique was implemented just to stay alive during peak hours and it consists purely on the following rules:

1. Never touch the server to regenerate the page more than once; unless it's absolutely necesary.
2. Use JavaScript to provide a state of who the user is and what privileges he has.

With those two rules in mind you may notice that jquery-tmpl with the basic amount of logic it provided was simply majestic for the given case. What I did basically is including the jquery-tmpl templates into the documents that required to be descontextualized. All the templates were provided by the page itself; so I could make a d18n javascript library which could do the following:

1. Query a really fast script about current user, return data as a JSON object.
2. Traverse the JSON and include the templates provided on the document on the specified selectors. Let jquery-tmpl do the math.

Whenever we needed to do a modification to the "tempalte" we would do it the same way as we would do it if there was no jquery-tmpl available: ON THE VIEW / PARTIAL.

You would view something like this for a "can user edit post?" template:

<script id="post-edit-button" type="text/x-jquery-tmpl">
  {{if user_id == "<%= post.user.id %>" || role == "staff" || $.inArray(user_id, EDITORS) }}
    <a href="<%= edit_post_url(post) %>">Edit</a>
  {{/if}}
</script>

Hope my experience is useful for you at some degree.

Ormuz

Answer 5

I use XSLT for this. Not everyone's a fan of its syntax, but it is crossbrowser, fast, and works - and you can even have client-side templating without much if any scripting at all by using a form targetting an embedded iframe - to have the advantage of small over-the wire documents (slightly larger than json, but not much). iOS devices don't support it; these would need to use the server-templated version - but the nice thing is that that's trivially possible with the same templates.

I'm not a huge fan of javascript templating libraries: they're complex, version-dependant, generally have poor tooling, liable to break as browsers change, and usually tie you to particular javascript libraries.

Ethbun