Merge lp:~wallyworld/launchpad/pillar-access-service-infrastructure into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Ian Booth |
Approved revision: | no longer in the source branch. |
Merged at revision: | 14863 |
Proposed branch: | lp:~wallyworld/launchpad/pillar-access-service-infrastructure |
Merge into: | lp:launchpad |
Diff against target: |
465 lines (+363/-0) 13 files modified
lib/lp/app/browser/launchpad.py (+2/-0) lib/lp/app/configure.zcml (+21/-0) lib/lp/app/interfaces/services.py (+37/-0) lib/lp/app/services.py (+37/-0) lib/lp/app/tests/test_services.py (+45/-0) lib/lp/registry/browser/configure.zcml (+9/-0) lib/lp/registry/interfaces/accesspolicyservice.py (+32/-0) lib/lp/registry/interfaces/webservice.py (+6/-0) lib/lp/registry/services/__init__.py (+1/-0) lib/lp/registry/services/accesspolicyservice.py (+45/-0) lib/lp/registry/services/configure.zcml (+18/-0) lib/lp/registry/services/tests/test_accesspolicyservice.py (+78/-0) lib/lp/services/webservice/services.py (+32/-0) |
To merge this branch: | bzr merge lp:~wallyworld/launchpad/pillar-access-service-infrastructure |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
j.c.sackett (community) | Approve | ||
Richard Harding (community) | code* | Approve | |
Review via email: mp+94338@code.launchpad.net |
Commit message
[r=jcsackett,
Description of the change
== Implementation ==
This branch provides an easy way to define and use named services having methods returning json data and supporting method parameter marshalling using the lazr restful infrastructure.
This work is required for disclosure. I wanted to introduce this new infrastructure rather than perpetuating the broken design of attaching service interfaces to domain entities. The lazr restful stuff suits quite well, but we will likely need to extend it to support marshalling operation parameters of type dict with IEntry objects for keys or values, rather than just references or lists.
Services are located using a simple traversal mechanism: "/services/
To define a new named service, simply create an interface extending IService, provide an implementing class, and register the service as a named utility in zcml. The service is then accessible via the url mentioned above.
The infrastructure to provide the zope url and navigation glue is provided by ServicesLink (for the top level services entry), ServiceFactory (for the traversal off the services link), and the IService url rules defined in zcml.
As well as the infrastructure to make it work, a sample service has been implemented, AccessPolicySer
I had trouble getting this all glued together. Even though all the exported methods and launchpadlib instance etc use version 'devel', I had to export the service implementations themselves for version 'beta':
export_
Until I did this, the wadl generation was broken. Thanks to wgrant for this bit.
== Demo and QA ==
Invoke a method on the access policy service from within a browser
or via launchpadlib:
from launchpadlib.
lp = Launchpad.
aps = lp.load(
aps.getAccessPo
or from an XHR call using an lp.client.Launchpad instance
launchpad.
== Tests ==
Add test for service traversal
Add test for service api invocation using a web services caller
Add test for service api invocation using launchpadlib
== Lint ==
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
The services utilities in registry/ configure. zcml can be moved into app/configure.zcml since none of the registrations use .registry domain objects. I think this is registering the objects used by LaunchpadRootNa vigation which I think is your change in LaunchpadRootNa vigation.