[ckan-dev] IFacets plugin interface

Toby Dacre toby.okfn at gmail.com
Mon Feb 18 12:19:24 UTC 2013


On 18 February 2013 11:46, Adrià Mercader <adria.mercader at okfn.org> wrote:

> On 15 February 2013 17:55, Toby Dacre <toby.okfn at gmail.com> wrote:
> >
> >
> > On 15 February 2013 17:47, Adrià Mercader <adria.mercader at okfn.org>
> wrote:
> >> Perhaps I would keep 1. making clear that these affect to all searches
> >> made, and that if you want a more efficient handlint you should use
> >> IFacets
> >
> > I'm happy to keep this but for it to be overridden if IFacet exists - is
> > that acceptable?
> Yes
>
>
> >> Will there be a way for defining facets for a particular dataset type?
> >> My use case: the harvester extension has a custom dataset type for
> >> harvest sources and on the listing page you can facet by frequency or
> >> type (two extras). How would I add these only to the harvest_source
> >> type and not the default dataset (or I can't)
> >
> > hmm,
> >
> > I suppose we could do something like
> >
> > IFacet.dataset_facets(dataset_type):
> >
> > that would let you do what you want but maybe it is not flexible enough
> - I
> > think you want something in the harvester extension that adds them for
> this
> > type.  Maybe we need a way to say I want to be called for datasets of
> this
> > type.  Lets's think about this.
> > What would work well/seems sensible for you?
> I think that would be enough, maybe also passing the default facets to
> extensions so they can update them or ignore them
> E.g on the package controller, search action
>
>     facets = default_facets
>     for item in plugins.PluginImplementations(plugins.IFacets):
>         facets = item.dataset_facets(facets, package_type)    # Let's
> use package_type for consistency
>
> Extensions would get the package_type, and decide whether to return
> the facets or not
>
> def dataset_facets(facets, package_type)
>     if package_type == 'harvest_source':
>         return facets.update({'frequency': _('Frequency'),
>               'source_type': _('Type'),})
>
> or
>         return {'frequency': _('Frequency'),
>               'source_type': _('Type'),}
>
> if they want to completely replace them
>
> If the extensions return nothing, no facets are used.
>
> Do this seem too complicated?
>
>
I'm quite happy to pass the existing facets.  For multiple extensions
altering the facets this also makes more sense and it is easy to add/remove
facets as needed.

To me this seems quite simple/flexible

I'm not so keen on the None returned but it would be easy to make facets =
{} if the returned value is not a dict instance

thanks


> Adrià
>
>
>
>
>
> >
> > good feedback - thanks
> >>
> >>
> >> On 15 February 2013 12:24, Toby Dacre <toby.okfn at gmail.com> wrote:
> >> > Facets are a problem in ckan.
> >> >
> >> > Currently they are changed via config options and the
> >> > IPackageController.update_facet_titles() translation of facet names is
> >> > not
> >> > fully supported
> >> >
> >> > The plan is to add a IFacet plugin interface to allow greater
> >> > flexibility so
> >> > that facets can be defined for
> >> >
> >> > Datasets
> >> > Groups
> >> > Organizations
> >> > Bulk Updates
> >> >
> >> > a function would be called on the interface for each of these to get
> the
> >> > facets and the display name
> >> >
> >> > eg
> >> >
> >> > def facets_datasets():
> >> >     return {'tags': _('Tags'),
> >> >               'groups': _('Groups'),}
> >> >
> >> >
> >> > the list may expand later if needed
> >> >
> >> > IPackageController.update_facet_titles() will be removed - this was
> >> > added in
> >> > 2.0 and I think Sven is the only current user and switching to the new
> >> > interface would be trivial.
> >> >
> >> > Do we also want to remove all the config options and just do things
> via
> >> > an
> >> > Extension?
> >> >
> >> > the issue is https://github.com/okfn/ckan/issues/400
> >> >
> >> > feedback?  I plan to do this over the next week.
> >> >
> >> > cheers
> >> > Toby
> >> >
> >> > _______________________________________________
> >> > 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
> >> >
> >>
> >> _______________________________________________
> >> 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
> >
> >
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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/20130218/045d542a/attachment-0001.html>


More information about the ckan-dev mailing list