[PATCH 6 of 6 json-style] tests: add tests for json output from hgweb

[Gregory Szorc]

On 12/31/14 2:45 PM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1420065389 28800
> #      Wed Dec 31 14:36:29 2014 -0800
> # Node ID 375310e882793f02023305f1065f616b0b42ab88
> # Parent  8a88b921f7b9b467046496ab6aa99d2589dd935c
> tests: add tests for json output from hgweb
>
> Now that we've added a json style, let's verify it works via hgweb.
>
> The added test file contains either a basic test or a placeholder for a
> test for every existing web command.
>
> Tests have been excluded for cases where JSON output isn't sane. For
> example, the "changeset" command invokes the templater multiple times.
> This "inner expansion" of values leads to the "outer" template
> encountering already-expanded JSON as a string, which it then proceeds
> to escape. The output JSON is valid, but the extra escaping is wrong.
>
> Upcoming patches will rework the templater to make this scenario work.
> hgweb commands will be fixed to use the new API and tests will be added
> to demonstrate they work as expected.

I wanted to stop here before going on because I wanted to save myself a 
lot of work in case others have fundamental objections to refactoring 
the templater.

Essentially, the magic and minimal json engine I added only works for 
templates that don't contain already-expanded templates. Unfortunately, 
there are a lot of templates that expand "sub templates" inline.

I think that inline expansion of final output formats like JSON and XML 
is quite silly. This is pretty much guaranteeing that there will be 
syntax errors or it will be very painful to avoid syntax errors. e.g. 
JSON not allowing trailing commas or YAML being sensitive to whitespace. 
I think giving the templater a large data structure and recursively 
expanding/serializing that is the way to go.

Unfortunately, getting there is a lot of work. I'd like to teach the 
templater about non-final / deferred expansion. Essentially, instead of 
performing the expansion immediately and passing that string result to 
an "outer" template, we'd instead pass an object that says "use the 
result of this expansion." We would then teach the template engine how 
to expand those special objects when encountered. In the case of JSON, 
it would likely create a new dict and just json stringify the end result.

I'm confident this solution will work. However, there's a lot of nested 
expansion going on. I'd need to add deferred=False (or similar) 
arguments to a lot of functions. It's a lot of work and I imagine a bit 
contentious.

I could just as easily define explicit JSON templates for the json style 
(much like how we do with XML). But, it suffers from the existing 
drawbacks of partial expansion and feels kludgy. I like how the approach 
in this series could lead to a world where templates "just work" for 
machine readable output formats.

Thoughts?