Forums

You should think about data and rendering separately.

A great structure for a web app is to build a RESTful JSON data API, a server-side front end using a web app framework (such as Spring MVC), and a client-side UI using something like the YUI App Framework.

This way the server-side front end and the client-side UI can both be "clients" to the data-only API. Additionally, together these three parts form your web app, but they remain decoupled and can therefore rev independently.

*Note:* You will probably end up using the same server-side web application framework to build your data-only API.

Now you have a standardized interface (JSON via RESTful HTTP) to your backend system(s) and database. The other two parts of your web app work together to form a human UI which communicates with that machine/data API.

There server-side front end and client-side UI traditionally differ in two major ways: their lifecycle, and context. The server-side serving all user of the application and its context lasts for the lifecycle of a single HTTP request that its fulfilling. The client-side UI is specific to a particular user and its context is long lived and is around for many requests (thing single-paged app making Ajax calls). Given these differences, fundamentally they are doing the same thing, rendering the data of an application and responding to actions by the user (HTTP request to the server-side, and DOM interactions on the client-side).

The patterns you'd use when building a client-side UI with the YUI App Framework are conceptually very similar to what'd you do in a server-side front end: Handle requests for a particular URL and render representation of that resource that represents the current state (data). They both have route handlers which load data (from the data API) into models, then render that data against a template.

When using Y.App, you'll want to make sure it can produce the same (or very similar) rendered state in response to the URL changing (pushState) that the server produces when refreshing the page at that same URL. <-- This is the progressive enhancement story.

You will see in the two example Y.Apps that I've build the model's `load()`ing data inside the route handlers, this is the same thing you're used to doing on the server:

* http://yuilibrary.com/yui/docs/app/app- ... tml#routes
* https://github.com/ericf/photosnear.me/ ... app.js#L94

Once the data is loaded in the models, that data is then passed to a Y.View so it can be rendered to a template and then inserted into the page's DOM.

Using something like Y.App start to be so similar to what you're already doing on the server that an opportunity to share code between the client and server arises. In the most recent version of Photos Near Me I've done that and it share the exact same Y.Models, Y.ModelLists, and Handlebars templates on the server and client! You can checkout the Open Hours video where I talk about this:

http://www.youtube.com/watch?v=Bjs7b8sksO4&hd=1

Framework like Mojito take these code sharing concepts even further by trying to abstract away the difference between code running on the client or server enabling someone to not only share models and templates but also route handling logic.

Does this help answer your questions?

So, after some further investigation, I now realize that Handlebars is an extension of Mustache that in fact makes it incompatible with Mustache and that it has poor Serverside support (unless you use Node.js). Whereas it's dead easy to work with Mustache on the server in Java, it's not at all with Handlebars. There are some sporadic references to Rhino here and there but it all looks like a major headache. Darn.

But wait. Since Handlebars is syntactically compatible with Mustache, one way forward is to use mustache.java and avoid any of the Handlebars extensions.

So, assuming one is not ready to throw up ones hands in frustration and quit at this point, the next question is: how to provide a fluid development experience.

You want to write a template only once, so that would mean
* Having the code mustache code that is used to compile the HTML page


* And a Handlebar template, that is used to insert into the HMTL page


* Or compiled to Javascript and deploy (somehow) through the YUI Loader

So it would seem to make sense to have a wrapper template that just does


Ideally, I want to deploy Handlebar templates through the YUI loader. Including them in the returned HTML just seems a little inelegant, although it would certainly be workable. This means that I need to compile the handlebar templates and make my serverside YUI CombiLoader smart enough to be able to handle handlebar templates.

One thing I really *don't* want is to have to execute some compiler action, every time I change a Handlebar template. I want a simple change/save/reload experience.

Questions that then come up with me are:
* What would be a good way to request pre-compiled handlebar templates through the YUI loader? Do you have to define a YUI component for each handlebar template?
* How to create a simple change/save/reload experience in Eclipse?
* Assuming one is not on Node.js what are practical suggestions to make it all rock?

Marc

For precompiling templates, have you checked out the information in the Handlebars user guide? While it's somewhat Node.js specific, the concepts can still be applied to other server-side environments:
http://yuilibrary.com/yui/docs/handleba ... -templates

You could breakup your templates into separate modules and even combo load them together just like other YUI modules. Pat Cavit has done just that, and describes in code how he's doing it:
https://gist.github.com/cb8e25c334fd7c21367c

For Photos Near Me, I created one dynamic YUI module to hold all of the precompiled Handlebars templates. In fact I even used a Handlebars template to construct the dynamic module
https://github.com/ericf/photosnear.me/ ... handlebars

The modules which subclass Y.View simply require the `pnm-templates` modules. Here is the code which handles the HTTP requests for the dynamic templates module:
https://github.com/ericf/photosnear.me/ ... js#L79-111

To integrate with Eclipse, you will want to create a builder which is triggered on save and will compile your templates by running a command line script and using this method to precompile your templates:
http://yuilibrary.com/yui/docs/handleba ... mmand-line

Nothing about these concepts or processes is specific to Node.js, they can implemented in any server-side system.

But like you said, if you limit yourself to just the Mustache syntax for your templates you'll be fine since Handlebars is a superset.