[ckan-dev] Packaging theme and model customisations

Thu Feb 10 14:42:55 UTC 2011

On 10 February 2011 14:21, Seb Bacon <seb.bacon at gmail.com> wrote:
> On 10 February 2011 11:16, Friedrich Lindenberg
> <friedrich.lindenberg at okfn.org> wrote:
>> Hi Seb,
>>
>> in general: have a look at https://bitbucket.org/okfn/ckan-nl where
>> Richard did a fantastic job of putting together a simple theme overlay
>> for some basic pages (especially look at the way layout.html is used
>> to override some things from layout_base.html). For a customization
>> that includes a custom form and some plugins, see:
>> https://bitbucket.org/okfn/ckanextiati
>
> Thanks -- and what would be the preferred pattern for setting
> extra_template_paths from within an extension?
>
> Would we just expect the person deploying the system to edit the ini
> file to point there, or should we instead register it when the
> extension is loaded?

I'd certainly avoid changing config in the python source of the
extension as that is fraught.

I think the person deploying the system should add options to the main
config file (e.g. ckan.net.ini) either manually, or automatically
through James' packaging system.

For tests requiring config, I suggest you copy what I've done in
ckanext-dgu, putting options into ckanext-dgu/test.ini, which refers
to the main test config 'use=../ckan/test-core.ini'.

Dave

>
> Seb
>
>> On Thu, Feb 10, 2011 at 11:39 AM, Seb Bacon <seb.bacon at gmail.com> wrote:
>>> 1) A template override for the homepage, with some custom functionality
>>
>> For the home page, overlay home/index.html
>>
>>> 2) Some local CSS (override layout_base.html?)
>>
>> I think there is a file called extras.css that CKAN looks for by
>> default but thats not included in the clean install. Just create one
>> and your rules will be looked at after the main style sheet.
>>
>>> 3) An extension to the package model (two extra fields which aren't
>>> implemented with PackageExtras
>>
>> Wow, what do they do? Can they not be modelled in some way? Otherwise,
>> serious monkey-patching of model/package will be in order. But,
>> please, what are your reasons? (This sounds like a maintenance
>> nightmare tbh)
>>
>>  Friedrich
>>
>>>
>>> (I realise for (3) PackageExtras would probably be the way to go, but
>>> for various reasons might not be practical in this case).
>>>
>>> Thanks
>>>
>>> Seb
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>>
>>
>
>
>
> --
> skype: seb.bacon
> mobile: 07790 939224
> land: 0207 183 9618
> web: http://baconconsulting.co.uk
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>