-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12-01-24 07:50 PM, Robert Collins wrote: > we really need to consolidate our template languages somewhat, as > part of streamlining LP and reducing maintenance surprises / > learning curves. > > So, I propose that we take 'stache as the baseline *for now*:
Mustache's main advantage as a templating language is that it is cross-platform. But both the Python and JavaScript versions need a lot of work. The JavaScript version, in particular, might need to be re-implemented along the same lines as Handlebars in order to fix its performance issues. And it's pretty clear that the implementations are not tested for interoperability-- I found obvious bugs on both sides. So if we make Mustache our main templating language, I think we'll be investing a lot in it. And I'm not sure it's a language we would otherwise choose to invest in-- the syntax is overloaded and weird. Maybe that effort would be better spent on writing a template language with saner syntax and guaranteed uniformity between implementations. As you say, the codebase is tiny, so implementing something comparable should not be a big job. In any case, I think it's a bad idea to use Mustache extensively on the python side until we're running a version that has https://github.com/defunkt/pystache/issues/8 fixed. The current release, 0.3.1, still suffers from it. > - when touching a template consider migrating it across - and > consider migrating templates as an itch-scratching exercise. If we're going to make a big commitment to a language, we should be confident that it's a language we want to be using. As a language, I think Mustache is worse than pretty much any other template language I've encountered. I would use it tactically, where no other template language is appropriate. > I think this should be treated as an evolutionary step: if 'stache > won't do the job, we need to find a different template language > that will, while still being both server and client side available > (to accelerate our migration to an API driven client side app). I don't think Mustache is particularly compatible with the web service API. It wants dumb objects, not Restful API wrappers. And it wants them organized in ways that the API does not support. The client-side and server side renderings of dynamic bug listings are identical because it *avoids* the web service API, and instead uses the JSONRequestCache on both sides. This allows Launchpad to generate the exact data that Mustache wants to consume. I believe this will be the winning technique whenever we want to support client-and-server-side rendering. If we move to client-only rendering, then it's possible we'd use the web service API, but we wouldn't have to use Mustache, either. > Last resort, we could write one : but that is the last resort. Personally, I'd rather wait for something better than switch whole-hog to Mustache. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8gHtgACgkQ0F+nu1YWqI3DNgCfXHfGnxufgynwggseN+HyJrJ2 rCIAn1QqKJ1YXnALeGGCotq82rI7T43v =ZyMt -----END PGP SIGNATURE----- _______________________________________________ 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
