launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

The e-dome was pretty cool; one of the things that got some air-time
there was template languages, and YUI 3.5 which has a new one -
handlebars, a derivative (of sorts) of moustache.

I've been poking around handlebars to evaluate what it would take to
write a python implementation - I think its pretty shallow - the
language is wide open to compilation into python (and that can be
compiled into bytecode, so we'd have a pretty snappy implementation).
However, handlebars seems to miss the point of no-logic-in-templates
with the turing complete extension points it has baked in.

We have a mix of the following template systems in LP today (this may
be a subset):
 - hand rolled [and hand escaped!]
 - tal
 - metal
 - simpletal
 - moustache (using one-template two-implementations to do client side
rendering)
 - chameleon (which is tal +- glitches, but not a trivial drop-in)
 - email forms (I haven't checked the implementation, but I think its
just string substitution)

While I'm very open to the idea that we need different (small) DSL's
I'm not convinced that template rendering is large enough to cover
multiple domains - 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*:
 - lets start doing all new pages in 'stache
 - record friction doing this on
https://dev.launchpad.net/MoustacheTemplates (not created yet)
 - the codebase is tiny, we can fix bugs in the js or python versions
pretty easily
 - ditto performance AFAICT the implementation today is just written
by a ruby dude that doesn't know python. (it is quadratic on the
number of expansions required).
 - when touching a template consider migrating it across
 - and consider migrating templates as an itch-scratching exercise.

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). Last
resort, we could write one : but that is the last resort.

Now, there are some questions around how to do great code and template
reuse that surround 'stache - and the handlebars answers are one
approach - if we need them, we will need to do a pybars (which will be
fairly straight forward). From my looking at it though, I am not
convinced that this is really a big deal. The primary thing (to me)
would be to make the view a -little- more dominant than it is in our
current setup, which is a necessary condition anyhow, if we want to
move to templates rendering 'just data'.

What-do-you-all-thinkly-yrs,
Rob