[ckan-dev] Alternatives to IGenshiStreamFilter?

Tue Oct 25 09:57:13 UTC 2011

Sean,

This is a good point, the stream filter can be broken easily by using the
templates changing, either through installing a different themes or a newer
CKAN version.

Rufus previously made the point that it should really be a theme which
decides how to present an extensions' visual items, rather than the
extension.

In addition I think at the moment very few extensions attach themselves to
the common areas of the UI. If a pattern emerges, such as tabs to the
dataset page (like you mention) then we should definitely build more
future-proof infrastructure for it like you suggest. But for the moment, I
think we just need to be aware of the danger, stay flexible and indeed enjoy
the flexibility to be creative.

David

On 22 October 2011 15:38, Sean Hammond <snhmnd at gmail.com> wrote:

> Hey,
>
> I noticed that CKAN extensions that need to modify the HTML templates
> tend to implement the filter() method of the IGenshiStreamFilter
> interface and do something like this:
>
> stream = stream |
> Transformer('body//div[@class="dataset"]').append(some_html)
>
> i.e they use XPath to search for a particular HTML element in the genshi
> stream and append to it.
>
> The problem is that changes to the CKAN templates can break the
> extensions.  The templates are effectively part of the interface that
> CKAN presents to extensions. Also, I imagine that it a CKAN instance has
> many extensions installed and they're all modifying the templates like
> this, the results could get messy.
>
> Would it be better to have a more controlled way for plugins to show
> themselves to the user? For example when viewing a dataset the user sees
> three tabs View, Edit and History. Perhaps there could be an interface
> that lets plugins implement a method that returns a link icon, relative URL
> and link text for the plugin's own tab bar item. There could be several
> methods like this allowing plugins to add themselves to different parts
> of the HTML.
>
> The point is that the HTML templates could change without necessarily
> breaking the plugins. It should also help to keep the HTML nice and tidy
> and the user interface nice and regular when extensions are being used,
> and stop extensions from stepping on each other's toes.
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20111025/9d5f1ab3/attachment-0001.html>