On Oct 17, 2011, at 1:55 PM, Robert Collins wrote: > On Sat, Oct 15, 2011 at 10:13 AM, Aaron Bentley <aa...@canonical.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all, >> >> I've just given Launchpad the ability to render a given template either >> server-side or client-side. I've done this because the >> CustomBugListings feature means we'll want to render bug listings on the >> client and server sides, and we have a new design for them. >> >> Here's a screenshot of the current work: >> http://people.canonical.com/~abentley/mustache-listings.png >> >> I've used the Mustache templating language for this. The Python >> implementation is called "Pystache", and the JavaScript implementation >> is called "mustache.js". >> >> In either language, the inputs are a string and a JSON-compatible >> mapping (a dict in Python, an object in JavaScript). In Javascript, you >> render a template like so: "Mustache.to_html(template, data)". In >> Python, it's "pystache.render(template, data)". > > This is pretty cool. I a question to help me (and perhaps others) > choose when to use *stache templates: > > - how does the server side generation compare to TAL performance? We > have pages that spend extraordinary amounts of time in TAL (and > have/are trying things like new TAL engines to improve on this).
Heh, if it is not loads faster, that will be sad. I expect TAL has a lot more functionality than mustache, for better or worse. For apples-to-apples, though, we ought to compare dict rendering of TAL versus *stache > > And an observation: the discipline of having a plain ol mapping will > help us develop eager-loaded datasets rather than just-in-time > evaluation, which I think will help with our query counts and server > rendering performance. Yeah. Gary _______________________________________________ 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
