[ckan-dev] Semantics behind package_type and retrieving of IDatasetForm plugins?

Thu Feb 13 23:45:55 UTC 2014

Hey All,

I'm new to the CKAN code base and am looking at extending it to do a few
new things specific to our use case. I have run into an issue I don't fully
understand and thought the list might be helpful. Please excuse me if the
topic has come up before. I poked around the archives but didn't see
anything related.

I would like to create multiple user facing endpoints for interacting with
the same set of packages/datasets. Each endpoint would have different
schemas for validation and templates for presentation, but  would be able
to read and write to the same set of packages between them.

A quick read of the Extending Docs suggested that implementing IDatasetForm
for each of these endpoints would enable this nicely. After messing around
with it though, that seems to not be the case: The read & edit actions on
PackageController check the persisted package_type--rather than using the
url to guess like the new action does--and this type value is used lookup
the relevant plugin.

So for an example, let's say we have these plugins installed:

class DatasetRequestPlugin(plugins.SingletonPlugin, tk.DefaultDatasetForm):
>     ...
>     def is_fallback(self):
>         return False
>     def package_types(self):
>         return ['request']
>
    def new_template(self):

        return 'request/new.html'

    def read_template(self):

        return 'request/read.html'

class AuditorJournalPlugin(plugins.SingletonPlugin, tk.DefaultDatasetForm):
>     ...
>     def is_fallback(self):
>         return False
>     def package_types(self):
>         return ['audit']

    def new_template(self):

        return 'audit/new.html'

    def read_template(self):

        return 'audit/read.html'

I would like for these two plugins to be able to share packages and do
different bits of the work in maintaining the metadata on these packages,
but creating a package by going to /request/new ensures that the
DatasetRequestPlugin will always be used to view or make edits. If you were
to go to /audit/mydataset, the DatasetRequestPlugin would still be
delegated.

I have a few questions related to this:

   - First, is there an obvious way to accomplish my goal that I have
   skipped over? That would be wonderful!
   - Failing that, is modifying the controller to behave differently a
   prudent course of action here? (I tried editing the package controller
   directly to check `_guess_package_type()` rather than `_get_package_type()`
   on read & edit, and it appears to nominally be viable.) I do not understand
   fully though what package_type is doing in other parts of the system, and
   would like to get a more informed take on how viable that approach is.
   (...and also how to accomplish the patch without editing ckan sources
   directly. My fumbling attempts at monkey patching have yet to pan out.)
   - Lastly, would the community be open to allowing plugins
   implementing IDatasetForm to be selected using information derived from the
   request url rather than the persisted package_type? Are there any clear
   reasons not to pursue this? I am not suggesting a change to the meaning of
   package_type, but perhaps a new lookup mode enabled by a cfg setting that
   carries different semantics with it.

Thanks for any help you folks can provide!

-Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20140213/53562043/attachment-0002.html>