-
-
-
-
-
-
This is more of a developer comment and less of a documentation comment. Doc blocks should always describe what the function does, which may be different than the reason the function exists. Maybe just make these normal comments.
-
-
I'd prefer just doing a standard: for url_patterns in self.resource_url_patterns_queue: self.add_to_url_patterns(url_patterns) It's a little more standard and readable, whereas using a while loop and pop is less common. It's also potentially faster (in theory) due to fewer method calls and optimizations for iterators. We can then just reset the list after the loop.
-
I'm not really sure I love this class modifying the extension's state, especially using public variables. If an extension author tried to use this variable, checking first that Extension itself didn't define it, then we'd end up stomping over it. Maybe instead we should have a dict owned by this resource class that maps extensions to the pending patterns. That way it's fully contained.
-
-
If this is for private use only, I'd prefix the name with a _. Same with any other private functions/variables for the URL building.
-
-
You can just have this as a parameter to the function: def notice_initialized_extension(self, sender, ext_class=None, **kwargs):
Allow Extensions to extend the WebAPI
Review Request #1648 — Created June 8, 2010 and submitted
This diff relies on this review request: http://reviews.reviewboard.org/r/1618/diff/6/ And also integrates http://reviews.reviewboard.org/r/1623/ We want extensions to be able to extend the API with their own resources. So if I have an extension RBDefects, with a resource Defects, I could access that resource here: ROOT/api/extensions/rbdefects.extension.RBDefectsExtension/defects/ Each resource is keyed to the extension they belong to, so requests to /api/extensions/[anything but rbdefects]/defects/ will return a 404. Extensions define their own resources, and then supply them to the Extension through a class list called "resources". This patch also includes code to create new tables for extension models. Evolve has not been integrated, since I'm still working on refactoring it to work nicely.
Performed rudimentary tests with an extension with multiple resources. Seemed to work out.
- Change Summary:
-
Thanks for the feedback - updated to reflect the comments. Probably the most significant change here is that I've switched from storing generated URL patterns in Extensions, and instead store those URL patterns in a dict within ExtensionResource, with the Extension as the key.
- Description:
-
~ This diff relies on this review request: http://reviews.reviewboard.org/r/1618/diff/5/
~ This diff relies on this review request: http://reviews.reviewboard.org/r/1618/diff/6/
And also integrates http://reviews.reviewboard.org/r/1623/ We want extensions to be able to extend the API with their own resources. So if I have an extension RBDefects, with a resource Defects, I could access that resource here:
ROOT/api/extensions/rbdefects.extension.RBDefectsExtension/defects/
Each resource is keyed to the extension they belong to, so requests to /api/extensions/[anything but rbdefects]/defects/ will return a 404.
Extensions define their own resources, and then supply them to the Extension through a class list called "resources".
This patch also includes code to create new tables for extension models. Evolve has not been integrated, since I'm still working on refactoring it to work nicely.