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