[ckan-dev] Theming: Improving widgetization and ability to enhance from outside core

[Rufus Pollock]

There's no suggestion of rushing this but I would be eager for us to
progress discussion on this promptly (like your excellent email
below).

Rufus

On 23 March 2012 10:12, Toby Dacre <toby.okfn at gmail.com> wrote:
>
>
> On 22 March 2012 10:53, Rufus Pollock <rufus.pollock at okfn.org> wrote:
>>
>> We want to make it easier to theme and especially to extend themes.
>> Our current approach using transformation of the genshi streams
>> objects:
>>
>> Problem:
>>
>> * We want to remove the Transformer usage due to performance and its
>> close tie to genshi
>>
>> * Want a standard way for core code and extensions to put code into
>> the templates where *templates request it* (templates control
>> insertion rather than extensions ...)
>>
>> * Stacking versus overwriting on entry points
>>    * Relationship to h.requires('jquery', version) -
>> http://codex.wordpress.org/Function_Reference/wp_enqueue_script
>>
>> Options: two main ones placeholders or helper methods (which are
>> essentially equivalent)
>>
>> * Placeholders: {{user _info}} {{sub_menu}} is this equivalent to
>> <span class="insert-user-info"></span>
>>
>
> {{placeholder}} isn't going to work as it could also be legitimate content
> <fragment>name</fragment> or something similar is uglier but doesn't have
> these problems
>
>
>>
>>    * Equivalent to helper method via: {{xyz arguments}} ->
>> h.load_snippet('xyz', arguments)
>>
>> * ${h.load_snippet()}
>>
>> Proposal: move to h.load_snippet model with a dedicated extension
>> point for extensions to define 'snippets'.
>>
>
> I still think this needs more thought especially looking at all the current
> usecases for filters so we can ensure that they are all met.
>
> h.load_snippet() is very similar to the current genshi include (excluding
> any stacking)
>
> {{placeholder}} vs h.snippet() have different behaviours and give us a
> different set of pros and cons
>
>
> IMHO we need to start this process by ripping TDH out of core (which david
> has graciously asked me to do) and look at ways to improve the integration
> of extensions into core.  The javascript stuff may be a good place to
> start.  I think we also need to be much clearer about what we are trying to
> achieve and why - for example at our meeting you explicitly said that
> performance was not an issue that you cared about.
>
> I am also keen to try to reduce the stuff going into the templates eg h
> already looks like
>
> ['AlphaPage', 'BR', 'Doctype', 'HTML', 'Message', 'ModelTags', 'OptGroup',
> 'Option', 'Options', 'OrderedDict', 'Page', '_Flash',
> '_VALID_GRAVATAR_DEFAULTS', '__builtins__', '__doc__', '__file__',
> '__name__', '__package__', '_add_i18n_to_url', '_flash',
> '_pylons_default_url', '_redirect_to', '_routes_default_url_for',
> 'am_authorized', 'are_there_flash_messages', 'auto_discovery_link',
> 'auto_log_message', 'beaker_cache', 'button_attr', 'check_access',
> 'checkbox', 'ckan', 'config', 'convert_boolean_attrs', 'css_classes',
> 'dataset_display_name', 'dataset_link', 'date', 'date_str_to_datetime',
> 'datetime', 'datetime_to_date_str', 'default_group_type', 'dump_json',
> 'email', 'end_form', 'escape', 'facet_items', 'facet_title', 'file',
> 'flash_error', 'flash_notice', 'flash_success', 'form', 'format_icon',
> 'fromstring', 'get_available_locales', 'get_locales_dict', 'gravatar',
> 'group_link', 'group_name_to_title', 'hidden', 'i18n', 'icon', 'icon_html',
> 'icon_url', 'image', 'javascript_link', 'json', 'lang', 'link_to',
> 'link_to_if', 'link_to_unless', 'linked_authorization_group',
> 'linked_gravatar', 'linked_user', 'literal', 'mail_to', 'markdown',
> 'markdown_extract', 'nav_link', 'nav_named_link', 'ol', 'pager_url',
> 'paginate', 'parse_rfc_2822_date', 'password', 'radio', 're', 'redirect_to',
> 'render_datetime', 'request', 'required_legend', 'resource_display_name',
> 'resource_icon', 'resource_link', 'select', 'stylesheet_link', 'submit',
> 'subnav_link', 'subnav_named_route', 'tag_link', 'text', 'textarea',
> 'th_sortable', 'time_ago_in_words_from_str', 'title', 'truncate', 'ul',
> 'url', 'url_escape', 'url_for', 'url_for_static', 'urllib',
> 'xml_declaration']
>
> I plan to add a ckan.restrict_template_vars (default False) that will limit
> this sort of stuff to a more manageable quantity of helper functions (plus
> then look to actually provide some documentation for them).  To me this is a
> higher priority as far as allowing us to make future changes.
>
> So to sum up I think that this is something which we should mull over for a
> bit longer before making any specific decisions.  I readily accept that my
> knowledge of ckan is pretty low but experience tells me we should cut the
> 'bad' things out before adding more stuff and rushed decisions are sometimes
> regretted.
>
> Toby
>
>> Rufus
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>



-- 
Co-Founder, Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/