launchpad-dev team mailing list archive

[Marc Tardif <marc.tardif@xxxxxxxxxxxxx>]

* Robert Collins <robertc@xxxxxxxxxxxxxxxxx> [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.tardif@xxxxxxxxxxxxx>
Freenode: cr3, Jabber: cr3@xxxxxxxxxx
1024D/72679CAD 09A9 D871 F7C4 A18F AC08 674D 2B73 740C 7267 9CAD