CSW Abstraction and XML Metadata Upload #248
Conversation
…_caps CSW param (to reduce bandwidth), prioritize catalogue.py by callers, optimize download url parsing
…ecking according to CSW impl
… terms which are more than one word
|
does this branch still cover GNIP's 4 and 5? |
|
At this point it does. I believe Tom is working on getting the tests On Wed, May 30, 2012 at 9:06 AM, David Winslow
|
|
@dwins yes. I will pull out the GNIP 4 related functionality from this pull request. |
| @@ -1249,122 +1274,42 @@ def search_result_detail(request): | |||
| layer = None | |||
| layer_is_remote = True | |||
|
|
|||
| keywords = [] | |||
| if hasattr(rec, 'identification') and hasattr(rec.identification, 'keywords'): | |||
There was a problem hiding this comment.
Doesn't this belong in the catalog backend? If our catalog abstraction layer doesn't even provide a consistent interface (requiring hasattr) I would argue that it's too low-level. Let's shoot for this method to look more like:
def search_result_detail(request):
uuid = request.GET.get("uuid")
catalogue = get_catalogue()
record = catalogue.get_by_uuid(uuid)
return render_to_response('maps/search_result_snippet.html',
RequestContext(request, { 'record' : record }))
The idea here is that all the matching up of Layer to metadata and massaging into a template-ready format is done by the catalog backend.
There was a problem hiding this comment.
OWSLib already provides an abstracted request/response model; don't we already have an abstraction of CSW in OWSLib itself? If catalogue/catalogue.py commits to an OWSLib interface, with ISO as the metadata model, isn't this enough? I think it may be too much bloat too abstract from OWSLib a level higher, not to mention transforming many objects at runtime when we already have them in OWSLib's CSW and ISO abstraction.
There was a problem hiding this comment.
I didn't say anything about transforming objects, just putting the logic of matching Layers and Records into the backend instead of having it in the views. I would argue that this is more about choosing appropriate abstractions than adding new ones - is a catalog backend just a slightly smarter wrapper around owslib's CatalogueServiceWeb, or is it responsible for bridging the divide between Django models and Catalog records? I think we can choose the latter without adding bloat here, and isolating the catalogue record-wrangling code from the template-slinging seems worth it to me.
There was a problem hiding this comment.
I second David's opinion here.
On Tue, Jun 5, 2012 at 11:31 AM, David Winslow
reply@reply.github.com
wrote:
@@ -1249,122 +1274,42 @@ def search_result_detail(request):
layer = None
layer_is_remote = True
- keywords = []
- if hasattr(rec, 'identification') and hasattr(rec.identification, 'keywords'):
I didn't say anything about transforming objects, just putting the logic of matching Layers and Records into the backend instead of having it in the views. I would argue that this is more about choosing appropriate abstractions than adding new ones - is a catalog backend just a slightly smarter wrapper around owslib's CatalogueServiceWeb, or is it responsible for bridging the divide between Django models and Catalog records? I think we can choose the latter without adding bloat here, and isolating the catalogue record-wrangling code from the template-slinging seems worth it to me.
Reply to this email directly or view it on GitHub:
https://github.com/GeoNode/geonode/pull/248/files#r929575
There was a problem hiding this comment.
Is this approach more acceptable to put forth, then? : https://gist.github.com/2876384
There was a problem hiding this comment.
Yeah Tom, That looks like it! Thanks.
|
|
||
| connection = settings.CSW['default'] | ||
|
|
||
| class Catalogue(CatalogueServiceWeb): |
There was a problem hiding this comment.
The Catalogue abstraction in GeoNode should probably use encapsulation rather than inheritance to access OWSLib functionality - ie, maintain an owslib.csw.CatalogueServiceWeb instance as a member variable, rather than inheriting from it. That makes it explicit where we are using catalogue.Catalogue methods instead of ones from OWSLib (and we can easily review the code to minimize such access.)
|
FYI the GNIP 4 (XML metadata upload) specific functionality has been removed from this pull request (tomkralidis@00d3e17) and will be recast in a subsequent pull request. |
…mes as per config in settings
Conflicts: src/GeoNodePy/geonode/geonetwork.py src/GeoNodePy/geonode/maps/tests.py src/GeoNodePy/geonode/maps/utils.py src/GeoNodePy/geonode/maps/views.py
| else: | ||
| return self.keywords_region | ||
|
|
||
| def thumbnail(self): |
There was a problem hiding this comment.
Is this thumbnail used as part of the refactor?
There was a problem hiding this comment.
yes, in https://github.com/GeoNode/geonode/pull/248/files#L19L159 as part of the ISO output.
Ps/pki 1.4.12.2
This pull request is as per https://github.com/GeoNode/geonode/wiki/GNIP-5----Abstract-OGC%3ACSW-Functionality