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

[Toby Dacre]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120323/a79191fe/attachment-0001.html>