[ckan-dev] CKAN 2.0 training: advice for plugins?

Toby Dacre toby.okfn at gmail.com
Sat Jan 12 04:26:29 UTC 2013


Stefan sorry this was stuck in my drafts I wrote it a few days ago

On 8 January 2013 19:53, Stefan Wehrmeyer <stefan.wehrmeyer at okfn.org> wrote:

> Hi CKAN devs,
>
> I will give a CKAN/Openspending training next week and I am preparing
> right now.
>
> The client wants to cover the following CKAN subjects:
> - install, configuration, deployment
> - customization, theming
>

The main changes are the genshi to jinja2 templating changes and the {%
ckan_extends %} in particular.
JavaScript is now done via modules
JavaScript includes via fanstatic (resource.config etc) and how inclusions
happen (this is a big change)
Css now via less and can be overidden via custom.less for example (plus
building from less) cev vs production
ITemplateHelpers is the future as far as new extension features


> - API, visualizations
> - Drupal integration
> - Datastore
> - Geospatial features
>
> The problem: it makes no sense to teach CKAN 1.8 at this time (especially
> for theming), but popular extensions like spatial are not CKAN 2.0 ready.
>
> Today I converted ckanext-spatial to CKAN 2.0 (as best as I could,
> documentation is out of date).
> Here is my pull request on the topic, please review:
> https://github.com/okfn/ckanext-spatial/pull/3
>
> I will probably have to work from this branch during training.
>
>
I think it would be good to do some more work on this branch if you where
to use it for training there are several things that could be improved.

1) in plugin.py there are lots of from ckan... import ... these are really
bad as we want a clear separation between ckan and the extensions.  This
should be an important part of the training IMO as it is the cause of
breakages.

I recommend
we use `import ckan.plugins as p` as the sole import from ckan if we can do
it - this removes all the `from ckan.plugins imprt I...` and we get
p.toolkit too.

toolkit gives us _ and ValidationError

json can just be imported not from lib.helpers

we should not import config as we are passed it via IConfigurable

you are then just left with ckan.lib.search it is possible those classes
might be candidates for inclusion in toolkit I don't know enough about them
though.

2) p.toolkit.add_template_directory() is a cleaner way of adding template
path

3) The JavaScript is still very much 1.8 in 2.0 CKAN is no longer there and
we do things via the modules (this is quite a big change) and the resources
stuff is only partially implemented and the {% resource ... %} tags are
place misleadingly.

Other than that the extension is moving in the right direction.  I'm not
sure it would make a great example for training due to lots of 1.8
practices still being used.

good luck

Toby

My question: can anyone give advice or share some knowledge about
> teaching/using the features from the list above with CKAN 2.0?
>
> Cheers
> Stefan
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130112/ef24b940/attachment-0001.html>


More information about the ckan-dev mailing list