[ckan-discuss] Extension for generating US's /data.json standard

Mon Jul 1 11:29:08 BST 2013

On 30 June 2013 20:53, Joshua Tauberer <tauberer+consulting at govtrack.us> wrote:
> Hey, Toby.
>
> Just belatedly following up on this thread (inline below):
>
>
> On 06/03/2013 07:41 AM, Toby Dacre wrote:
>
> On 31 May 2013 21:07, Joshua Tauberer <tauberer+consulting at govtrack.us>
> wrote:
>
> Here in the U.S. the new Open Data Memorandum requires agencies to publish
> data catalogs in JSON with a particular schema. [1]
>
> For HealthData.gov, the Drupal/CKAN data catalog for the U.S. Department of
> Health & Human Service, we created a CKAN extension to generate the
> /data.json file. In case anyone from other U.S. agencies is on this list, I
> wanted to share our github project for the extension:
>
> ckanext-datajson: https://github.com/HHS/ckanext-datajson
>
> Hi,
>
> I had a look at your extension.
>
> some feedback this is assuming you are running CKAN 2.0 although I
> think it would also be valid for 1.8
>
> ```
> from ckan.lib.base import BaseController, render, config
> from webhelpers.html import literal
> from pylons import c, request, response
> ```
>
> BaseController, render, literal, c, request (unused) - can all be
> accessed via the plugins toolkit eg p.toolkit.render this will reduce
> the likelyhood of breakage of you extension in later versions of ckan
> due to code refactoring.
>
>
> Not all of that has landed in a release. It looks like BaseController didn't
> make it:
>
> https://github.com/okfn/ckan/blob/release-v2.0.1/ckan/plugins/toolkit.py
>
This will be in the 2.1 release
https://github.com/okfn/ckan/blob/release-v2.1/ckan/plugins/toolkit.py#L55

>
>
> config should not be imported directly from pylons use the
> IConfigurable interface to get/process the config this is the CKAN
> supported way for extensions to access the config.
>
>
> Got it.
>
> I ended up using IConfigurer. I wanted a config option to be able to control
> the path of a route, and only IConfigurer's methods are called before
> before_map/after_map.
>
>

This looks like it is a bug in ckan and we should do the IMapper stuff
after the config has completed
but your implementation should be ok as long as no other extension
changes these config settings which is unlikely
created an issue https://github.com/okfn/ckan/issues/1061

> from ckan.logic.action.get import current_package_list_with_resources
> ```
>
> actions should be accessed via p.toolkit.get_action(<name>) so that
> they can be overriden by extensions etc.
>
> also if the contexted is None then model will be autopopulated by the
> get_action() returned function so you do not import ckan.model
> ```
> packages = current_package_list_with_resources( { "model": ckan.model}, {})
> ```
> packages = current_package_list_with_resources(None, {})
>
>
> Got it. Much easier.
>
> Thanks again for looking it over and providing feedback. Really appreciated.
>
Glad it was helpful

> Josh


-- 
Toby Dacre

The Open Knowledge Foundation

Empowering through Open Knowledge
http://okfn.org/  |  @okfn