Merge lp://staging/~spiv/loggerhead/jsonify into lp://staging/loggerhead
Status: | Merged |
---|---|
Merged at revision: | 451 |
Proposed branch: | lp://staging/~spiv/loggerhead/jsonify |
Merge into: | lp://staging/loggerhead |
Diff against target: |
701 lines (+291/-129) 9 files modified
loggerhead/apps/branch.py (+3/-0) loggerhead/controllers/__init__.py (+14/-4) loggerhead/controllers/filediff_ui.py (+1/-1) loggerhead/controllers/inventory_ui.py (+32/-19) loggerhead/controllers/revision_ui.py (+63/-44) loggerhead/controllers/revlog_ui.py (+1/-4) loggerhead/tests/test_controllers.py (+136/-57) loggerhead/tests/test_simple.py (+31/-0) loggerhead/util.py (+10/-0) |
To merge this branch: | bzr merge lp://staging/~spiv/loggerhead/jsonify |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Vincent Ladeuil (community) | Approve | ||
Review via email: mp+66177@code.staging.launchpad.net |
Commit message
Expose /+json URLs for getting machine readable content for various pages.
Description of the change
This adds raw JSON output from special requests to Loggerhead. For controllers that support it, you can insert /+json into the URL to get the raw form (eg, /revision/head: is the HTML page and /+json/
To get there:
1) Refactor TemplatedBranchView children to make it clearer what values are "data" and what values are there just to support template expansion (turning paths into URLs, etc.) In general we don't return any URLs in the JSON, we return the rev-ids and file-ids and paths, and clients can build up URLs. This was the way to avoid issues with stuff like URL prefixes.
2) Lots of Loggerhead code likes to return "Container" objects (which are basically wrappers around dicts so you can say foo.attrib rather than foo['attrib'].) This needed JSON encoding, which is a pretty trivial wrapper.
3) Add a flag so that you can't ask for /+json for URLs that we haven't fixed yet. This is things like /changes, because we don't yet have a great answer for what data we actually want to return there. And for ones like /download where it is already just returning the raw content bytes, no need to wrap them.
4) Add decent smoke test coverage. To determine that JSON apis don't explode, and that get_values has content that seems reasonable.
This looks fine and brings some useful refactorings.
Did you get any insight about how to avoid regressions in the template/values separation ?