launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

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