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

[Paul Boddie]

On Wednesday 16 May 2012 23:30:19 Matt Mackall wrote:
> On Thu, 2012-05-03 at 01:08 +0200, Paul Boddie wrote:
> > # HG changeset patch
> > # User Paul Boddie <paul at boddie.org.uk>
> > # Date 1335996246 -7200
> > # Node ID b9e5bb3e97b3cbc4190bc020431d7f19e1f556b8
> > # Parent  d7c9976b930e1fdbf8608a65462cd124977c7d53
> > hgweb: make graph data suitable for template usage
>
> This is problematic in that it will break anyone's locally-customized
> templates. We should instead introduce a second graph data keyword. With
> defered evaluation, we can avoid calculating this data twice per
> request.

Thanks for reviewing the patch!

My first attempt at implementing this actually involved two separate sets of 
data for graphs - one using plain collections as is currently used by the 
JavaScript code, and one using mappings as is more appropriate for the 
templating system - but I then considered it somewhat tidier to provide only 
the mapping-oriented data and to write some JavaScript adapter code which 
hides the changes from the individual themes by converting the mappings to 
collections before the vertex function is called.

My impression was that the vertex function, included in the graph.tmpl file 
for various themes, was the point of customisation, so it would be safe to 
uphold the collection-oriented "interface" from that function's perspective 
whilst exercising the freedom to have an alternative internal representation 
in the mercurial.js code.

After I submitted this patch, I considered the issue that for SVG at least, 
browsers have to be able to handle XHTML, since inline SVG in HTML is only 
officially supported in an XML-capable "dialect" of HTML. Certain browsers 
have had problems with XHTML, most notably Internet Explorer, and a more 
reliable approach where plain HTML is concerned is to embed SVG diagrams 
using the "object" tag which in turn makes another request to acquire the SVG 
content.

So, what I would like to propose is actually a separate action (or "Web 
command") that only serves the graph content, not the navigational 
boilerplate around the graph, but only the graph nodes, edges and labels 
themselves. Thus, visiting the graph page for a theme using this alternative 
action would first serve up a Web page containing something like this:

  <!-- Some HTML for navigational purposes. -->

  <object data="/hg/somerepo/graphdata/123456789abc"
          width="..." height="...">graph only</object>

  <!-- More HTML for navigational purposes. -->

The "graphdata" action would then return the templated graph which would be 
embedded in the page. I'm not sure how awkward it would be to position and 
size this object nicely, but then it wasn't really straightforward to manage 
this using inline SVG, either.

Any thoughts on this?

Paul