[ckan-dev] Cleaner extensions

Mon Apr 16 16:09:02 UTC 2012

HI,

This is a general email with some thoughts about making the extensions
cleaner.  I've looked at some of our extensions eg googleanalytics, dgu,
ecportal, datastorer etc to get a feel for what we are doing in them.

Issues
=====

Templates
--------------

Currently our templates seem to be not as flexible as they could be eg we
have of copies of template files like _util.html in ecportal.
layout_base.html feels like it tries to do too much providing template
functions (importing _util.html), the base page ( html header css/js
includes CKAN js vars etc) and also general site content.

I'd like to move more content into snippets so that they are easier to
override examples would include things like pagiation(), activity_div() in
lib/helpers.py and much of the stuff in _util.html (function stubs would
remain for backwards compatibility) and also stuff currently in
layout_base.html like main menu, language chooser etc

I'd also move all page content into a separate include file that defines
the general page layout that can then be changed without affecting the base
page

Also from what I can tell extensions cannot add their own template
directories and this has to be done in the main ckan.ini file I'm not sure
if this is good or bad

Imports
----------

Our extensions seem to be of two types
1) either do not import anything from ckan or a limited selection of
modules from lib/base or lib/helpers and the general lib/plugins stuff
2) do invasive imports from ckan controllers/logic
functions/models/dict_functions

There does not appear to be much consistency. eg `import ckan.lib.helpers
as h` vs `from lib.base import h` or _ imported from base or directly from
pylons.

I think that helpers needs to be split into template helper functions
(nav_links, icons), more general helpers (url_for, flash messages) and
imported helpers (_, json) there is overlap between these function types
and unpicking it may be painful lib/base.py would likely be heavily
affected by such a change.

I'd like to have a general extensions lib that includes core stuff that
will remain supported long term what i'd term core stuff would include
things like _, json, url_for, get_action, render, config, ckanCommand etc -
extensions only using this functionality should then have much fewer
upgrade issues when we make internal changes to core

General
-----------
Extensions don't seem to have a nice way to require a min/max ckan version
that I could find
Turning plugins on and off programatically was problematic and may still be
The plugin documentation that I've seen does not go into much detail on how
to implement them and so developers may have to make best guesses

It would be good to know what other issues people are aware of

 Toby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120416/e6523717/attachment.html>