launchpad-dev team mailing list archive

[Richard Harding <rick.harding@xxxxxxxxxxxxx>]

On Fri, 27 Jan 2012, Marc Tardif wrote:

> 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].
...
> 
> 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.

There are a couple of ways this might go. Mustache does support
"functions" or lambda depending on which docs you read. So you could add a
function that does some date parsing logic to your objects as you pass them
to the template and that function would accept the date string coming from
the JSON and then try to pretty it up.

The other thing I've done is to implement the YUI MVC framework which
supplies the concept of Models. In this way you can define that a model
consists of the fields that JSON supplies as YUI ATTRS. Then you can
defined extra ATTRS with getter/setter methods in order to loop over your
data, create models for each, which sets the extra properties (in this case
a properly formatted date from the JSON date string) and then pass that to
the Mustache or other template logic. In this way, render is still one step
with a almost "compile to model" inner step. 

You can get a few other nice things from this though as models can have
other logic, events, and more that can help the front end flesh out a bit
more. In my case, in the View layer, when someone clicks the delete link
that the template generates, it fires a remove event on the model attached
to it, and the model then makes an api call to the server to delete the
object.

> 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.

Exactly, I think the API should always be trying to just provide the raw
data in a way that's friendly to all and wasting cycles providing you 4
different ways of displaying a date when you might not even care about the
date seems definitely wrong.


> Is this a valid concern or might I be missing something?

It's definitely valid. I think that as you move more of your display to a
pure client side consumer of API data you start to have to resolve issues
with getting things massaged so that you're not compromising how you do the
UI. This nice thing is that generally, the answers are very similar to how
they were before. If I treat my API as a database query, I often had to
massage the data coming out of that before handing it to my server side
template. I treat the JSON->Model interaction as the ORM layer of my client
side app.


-- 

Rick Harding

Launchpad Developer
https://launchpad.net/~rharding
@mitechie