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