[PATCH] hgweb: make graph data suitable for template usage

[Paul Boddie]

On Thursday 17 May 2012 20:48:08 Matt Mackall wrote:
> On Thu, 2012-05-17 at 19:09 +0200, Paul Boddie wrote:
> >
> > So should I do what I did originally and provide a separate variable with
> > template-compatible data, with the difference being that the sequence of
> > dictionaries (and perhaps the sequence of collections for the JavaScript
> > code) is generated as some kind of iterator?
>
> Yes.

OK, I'll look into doing that.

> > P.S. For a presentation in 2010, I looked at theming for Mercurial,
> > MoinMoin, Roundup, and planned to look at Mailman. It seemed to me that
> > the templates for Roundup were pretty complicated, and I can't say that
> > TAL is particularly nice to work with, either. In the end, I didn't
> > finish the Roundup templates.
>
> The comment is not about the template language so much as the tight
> coupling between template and app. Roundup's templates are ostensibly
> intended to be user-customizable, but upgrades tend to break them
> because old templates talk to old APIs that no longer exist.
>
> If your app needs a page that looks like this, with a bunch of manual
> steps for every upgrade:
>
> http://roundup.sourceforge.net/docs/upgrading.html

Yes, I saw this. I don't think I would want the job of maintaining an 
installation of Roundup based on that page, but that's mostly because people 
don't want to be given an open-ended task for something they can't really 
avoid: it becomes a huge distraction, and there's nothing worse than having 
to spend work/free time doing something other than what you're supposed to be 
doing.

> ..I don't want to administer it. So of course, I aim not to produce such
> an app myself. Custom templates from before 1.0 still work with the
> latest hg.

I've seen at least one case where a variable has changed in structure: I think 
it was "changenav" that changed. Some of these things are unavoidable, but 
that meant either targeting two separate eras of Mercurial versions or just 
dropping support for older versions (1.4 and earlier, I think).

> We obviously can't keep all the internals stable and still improve the
> code, so extensions (which by definition have access to all the
> internals) are the exception to the rule.

Sure. I was just wondering whether there was some kind of well-defined 
interface to the graph functionality in JavaScript. If the themes can do what 
they like, calling into the mercurial.js code as they see fit (that is, not 
just calling the render function and getting callbacks to the vertex 
function), then there's not much flexibility left for us.

But anyway, I'd rather not touch the JavaScript code, so having a different 
output for template-compatible data is completely fine by me.

Paul