[ckan-dev] pylons.app_globals vs pylons.config

[Toby Dacre]

On 29 April 2013 17:16, Sean Hammond <sean.hammond at okfn.org> wrote:

> > 8) do some validation of options at ckan start-up - including that it has
> > documentation.
>
> Yeah this would really help a lot.
>
> But even if we implement a CKAN options system in app_globals of
> wherever that has this sort of validation, how can we prevent code
> from just accessing some undocumented option via pylons.config directly?
> If we really want it to work we might have to monkey-patch something
>
>
One way might be to remove undeclared options from the config but that
might break many plugins so probably a bit mean.  We can write a test to
look for `bad` code in core trying to import things from pylons rather than
through lib.common that would be quite simple and effective.

Due to the plugins issue we will have to move plugins over first.  I think
that we could do this either by a plugins.toolkit function or just adding
an extra method to the IConfigurable Interface.  Of course we need to sort
core first.





> _______________________________________________
> 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/20130429/bf8bd853/attachment-0001.html>