* Robert Collins <robe...@robertcollins.net> [2012-01-25 13:50 +1300]: [snip] > Now, there are some questions around how to do great code and template > reuse that surround 'stache - and the handlebars answers are one > approach - if we need them, we will need to do a pybars (which will be > fairly straight forward). From my looking at it though, I am not > convinced that this is really a big deal. The primary thing (to me) > would be to make the view a -little- more dominant than it is in our > current setup, which is a necessary condition anyhow, if we want to > move to templates rendering 'just data'.
I've been wanting to move to templates rendering just data for another project where this is partly the case. The premise was that the web interface should be considered as just another client accessing the API as a motivation to make it feature complete. So, I wrote my own YUI widgets and plugins [1] which worked until they stopped working for me, as is often the case. The motivation for not using other libraries was not because they were inadequate but rather by pure negligeance on my part. However, the idea is essentially the same so changing to something like mustache should just be a refactoring rather than a redesign. The most significant limitation with my implementation was not being able to manipulate the variables in the template. For example, I very much like the idea of formatting a date on the client side so that the timezone is always correct (although I'm sure someone has an exceptional use case to the contrary). To solve this problem, I have a horrible hack that first tries to parse string values as a date and, if that succeeds, then formats it nicely [2]. So, I now looked at the documentation of mustache.js [3] to see how it might solve the same limitation. Unfortunately, it doesn't look like this library solves the problem either. Instead, I can think of a couple potential workarounds: 1. Make two passes over the data, once to massage the data and another time to render it. In other words, first render the raw JSON to cooked JSON and then the cooked JSON to HTML. I'm not so much concerned about the performance implication of rendering the same data twice as much as the nuisance of duplicating what is essentially display logic in two places. 2. Or, make sure the API always returns cooked JSON ready to be displayed without any further manipulation. If the webservice returning the JSON was not an API, I might agree with this solution. However, if the intent would be to query something like the Launchpad API to render in templates, then I would tend to disagree because I don't think the API should address display concerns in its values. Is this a valid concern or might I be missing something? 1. http://bazaar.launchpad.net/~launchpad-results/launchpad-results/trunk/files/head:/static/js/ui/ 2. http://bazaar.launchpad.net/~launchpad-results/launchpad-results/trunk/view/head:/static/js/ui/content.js#L306 3. https://github.com/janl/mustache.js -- Marc Tardif <marc.tar...@canonical.com> Freenode: cr3, Jabber: c...@jabber.org 1024D/72679CAD 09A9 D871 F7C4 A18F AC08 674D 2B73 740C 7267 9CAD _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
