[PATCH 12 of 20] hgweb, paper: add shortlogajax template and use it

[Alexander Plavin]

13.08.2013, 00:45, "Matt Mackall" <mpm at selenic.com>:
> On Mon, 2013-08-12 at 22:39 +0400, Alexander Plavin wrote:
>
>>  12.08.2013, 22:16, "Matt Mackall" <mpm at selenic.com>:
>>>   On Fri, 2013-08-09 at 22:57 +0400, Alexander Plavin wrote:
>>>>    # HG changeset patch
>>>>    # User Alexander Plavin <alexander at plav.in>
>>>>    # Date 1376061214 -14400
>>>>    #      Fri Aug 09 19:13:34 2013 +0400
>>>>    # Node ID d29091e49e209d58302e2835a3cdf63b6df7f8f2
>>>>    # Parent  d207510e86ed78f44521ce847283ac5abafa9eeb
>>>>    hgweb, paper: add shortlogajax template and use it
>>>   I get the extremely vague impression that this is the form that's used
>>>   by the client to fill in async requests..
>>  You are right.
>>>   If so, the sensible way to do it is to add a new xml style.
>>  The first idea and implementation I thought of was exactly this, a
>>  separate style (of course it still exists somehow, thanks to evolve :)
>>  ). It generated a well-structured xml style, i.e. all revision
>>  elements like hash or description were in separate machine-readable
>>  xml tags. However, this adds extra difficulty then: javascript will
>>  need to render this to html and add to this page, thus we need two
>>  things here. One is a separate template for entries, as the existent
>>  serverside one can't be reused for several reasons, and other is the
>>  actual template language and implementation of it (this language
>>  doesn't need to be as complex as serverside one of course, but it is
>>  needed).
>
> I see your point. Yes, this does nicely solve the problem of rendering
> in a DRY way. Though it seems it could be cleaner still: the client-side
> javascript could just request plain-old shortlog and strip off the
> wrapping HTML with a tiny bit more client-side code and no changes
> server-side.

I doubt that it would be the best solution. JS code needs to know the last-shown-revision hash or number, and if we just send the 'plain-old shortlog', we will need to get this info somehow. And as we can't predict all possible user-made custom themes (and motd, by the way - it will be on the page too), heuristics is the most that can be done there. So, as I see this problem, sending simple XML with ready HTML in it and a small piece of metadata (hash or number) is better.

>
> However, looking forward, we're probably going to want to do this sort
> of thing in more than one place, and probably not in ways where the
> pre-rendering helps. For instance, hover-over on an annotate line to get
> commit info or similar. As this data won't even be available without JS,
> there won't be any templates getting duplicated. So, while it may not
> make sense for shortlog infinite scroll, in the general case, I think
> AJAX features are going to want an XML style.

Fully agree here, though I didn't think much about other possible AJAXy things like annotate that you mentioned. And anyway, as for me, adding XML style should be done when it will be needed (it's almost clear that it will).

>
> --
> Mathematics is the supreme nostalgia of our time.