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

Matt Mackall mpm at selenic.com
Thu May 17 13:48:08 CDT 2012


On Thu, 2012-05-17 at 19:09 +0200, Paul Boddie wrote:
> On Thursday 17 May 2012 18:30:59 Matt Mackall wrote:
> > On Thu, 2012-05-17 at 18:23 +0200, Dirkjan Ochtman wrote:
> > > On Thu, May 17, 2012 at 6:15 PM, Paul Boddie <paul at boddie.org.uk> wrote:
> > > > Well, I'd rather keep the single graph action/resource and not have to
> > > > bother supporting legacy browsers, too. I've had feedback from someone
> > > > using the SVG-based theme I've developed and they told me that
> > > > subsequent IE versions seem to work fine, so maybe IE6 users just need
> > > > to get with the times.
> > >
> > > I think we've held that position for about 4 years now...
> > >
> > > I like your thoughts here, but you probably need a better backwards
> > > compatibility story to satisfy Matt.
> >
> > Indeed. Paul, as someone who maintains an out-of-tree theme, you should
> > be sensitive to the fact that changes like this could potentially be
> > very unfriendly to people who maintain out-of-tree themes. It's really a
> > nightmare when you do a routine update a web app <cough>roundup</cough>
> > and it breaks because all its templates are no longer compatible with
> > its core.
> 
> 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.

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

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

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.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list