Skip to content

Handlebars support in mojito. #143

Closed
wants to merge 5 commits into from

4 participants

@caridy
caridy commented May 5, 2012

Let's get the ball rolling for the handlebars support in mojito. This is just a preliminary job, I plan to add all the missing features into this branch to match the current mustache support. Feel free to reject the pull request for now.

For now, I also added the new yui->3.5.0 to the dependency list although only used by the handlebars engine implementation who requires yui/handlebars. Eventually, when the transition to the new YUI node package happens, should be easy to merge this changes.

Client side is mostly covered by yui 3.5.0, we just need to create the mojito wrapper for it.

TODO:

  • tests
  • figure out how to call done and composite.done without specifying the content-path as part of the view object.
  • create view-engines/hb.client.js as a wrapper for YUI 3.5.0 handlebars implementation

I don't plan to add support for {{> partial}} since that requires some extra machinery to resolves paths etc.

@FabianFrank

great job @caridy let me know if you need help :-)

@caridy
caridy commented May 5, 2012

If you want to try out the current implementation, check the demo here:

https://github.com/caridy/mojito-handlebars-demo

@caridy
caridy commented May 5, 2012

@Schnitz of course I need help jajajaja

@caridy caridy adding support for mojito compile views when running handlebars templ…
…ates. in the case of the mustache templates they are just strings, but handlebars produce javascript functions so we have to do a little bit of hackery to get it done within the mojito scheme for cached objects.
9316b9d
@drewfish drewfish commented on the diff May 8, 2012
source/lib/management/commands/compile.js
@@ -971,6 +991,12 @@ YuiModuleCacher.prototype.createNamespace = function(ns) {
_c: {},
cache: function(k, v) {
this._c[k] = v;
+ // exposing the cache object in case we want to do
@drewfish
Yahoo Inc. member
drewfish added a note May 8, 2012

This comment should really be a comment introducing the cache() method (plus add yuidoc tags).

@caridy
caridy added a note May 8, 2012

agreed, I will adjust it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@drewfish drewfish commented on the diff May 8, 2012
source/lib/app/addons/ac/partial.common.js
@@ -72,6 +72,32 @@ YUI.add('mojito-partial-addon', function(Y, NAME) {
}, meta);
},
+ /**
@drewfish
Yahoo Inc. member
drewfish added a note May 8, 2012

Why does this ac.partial.compiler() method exist? Where/how might it be used?

@caridy
caridy added a note May 8, 2012

Today, with mustache, we can add "mojito-partial-addon" and call for ac.partial.compiler('foo') to get the stringify version of the template, and pass it to the client side if we want to use that there.

With handlebars, we should be able to do the exact same. Here is an example:

https://github.com/caridy/mojito-handlebars-demo/blob/master/mojits/HelloHandlebars/controller.server.js

The difference between mustache and handlebars at this point is that mustache produce a string that has to be processed at the client side by the mustache engine, while handlebars produce a Javascript code that represents a function, and by calling that function, it will return the rendered template.

But from the mojito point of view, they are the same thing, so, ac.partial should behave the same.

@drewfish
Yahoo Inc. member
drewfish added a note May 8, 2012

Why would anyone want to call ac.partial.compiler() and send the results to the client side? mojito compile views is meant to take care compiling the views, so that nothing special has to be done in the controller.

@caridy
caridy added a note May 11, 2012

@drewfish "mojito compile views" is pretty dummy today (it doesn't select specific views per context, etc). Shaker does a better job in this area, but still I feel that, sometimes, having the ability to serialize a partial and sending it over to the client side to execute a particular process without all the hazard of compiling all of them during build time is a nice to have feature, specially if you have some sort of logic to pick the right view programmatically rather than a fixed value.

@drewfish
Yahoo Inc. member
drewfish added a note May 11, 2012

Hmm... OK. I would say that if ac.partial.compiler() is sufficiently useful (as you argue) then we should let it drive a change to the view engine API and require that -all- view engines (including mu) support it (via the new compiler method).

@drewfish
Yahoo Inc. member
drewfish added a note May 11, 2012

And we should perhaps update mojito compile views to be better about contexts, etc. It seems a little dangerous to invent a new feature when the old one isn't sufficient, when we could instead fix up the old feature. We don't want to end up with a million slightly-different ways of doing things.

@caridy
caridy added a note May 14, 2012

I will argue that this type of rollup process (mojito compile views) should be made by shaker rather than mojito itself. But about the specific feature we are discussing here (partial->compiler), I added to facilitate (in the near future) the use of {{> partial}} for handlebars templates. At this point, mojito-partial-addon is the only external addon that knows how to resolve (based on the name of the view) the partial fullpath, etc. So, if we are going to support this feature anytime soon, we need a way to pre-compute partials before executing the composite view. That being said, we can stick to the plan of having no compiler routine at the addon level if you feel strong about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@isao
isao commented May 10, 2012

looks like this won't apply cleanly now, sorry. but really looking forward to it.
side note: since views are .hb. it doesn't need to be 100% interoperable with the mojito mu implementation

@caridy
caridy commented May 11, 2012

@isao, the idea is to have the same support since mustache is a subset of handlebars, so we can drop mustache implementation and still support *.mu.html files as an alias of *.hb.html. I don't see why we need to have both when handlebars can perfectly handle mustache templates.

@drewfish
Yahoo Inc. member

Sorry, I didn't mean to let this pull request linger so long.

If you made a pull request that just added handlebars, it would likely be accepted pretty quickly.

The ac.partial.compiler() stuff worries me. I'm worried that it is taking Mojito in the wrong direction. If/when Mojito supports "partial" (which I think of as "includes") in templating engines, that shouldn't have to involve the controller (or even addons or ActionContext) -- it should just work (from the view of the developer using Mojito).

@caridy
caridy commented May 24, 2012

sure, let's close this one then. I will pull another next week!

@isao
isao commented May 24, 2012

Looking forward to it, thanks Caridy

@isao isao closed this May 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.