Easy context hooks for plugins

[Christopher Allan Webber]

We now have template hook support. But maybe you want to add things to the context!

We'd like to make this fairly easy. One way to do it is probably make it so you can lazily attach plugins to the context, even without making an extra call.

This might work like so:

• Extend the MediaGoblinApp to attach request.view_name onto the request, which is the path to the view (maybe even its "logical name" used to look up that view name in the routing, or just the pythonpath to that view)
• Whenever render_to_response is called, it checks to see if there's a hook for that view name and template, like so: PluginApi.get_hook_callables("some.view.name-mediagoblin/something/template.html-context") (yes, this is overly-verbose, one other option is to start namespacing hooks and use a tuple of (view_name, template_name) as the key)
• Iterate through each of those functions passing in the context so plugins can mess with the context dict.

[Elrond]

Some notes:

filters

get_hook_callables("some.view.name-mediagoblin/something/template.html-context") is quite verbose and possibly okay for a specific case. But it makes things very ugly, if a plugin wants to modify *all* contexts.

So I would rather propose a more generic, namespaced calling scheme. Maybe like the registering works like this: pluginapi.register_namespaced_hook("context", filters, hook_fn). That way for filters=None, the hook is called for every render_to_response.

hook calling convention

We need to get a calling convention for the context hook. It's not as simple as passing in the context. If it gets called for each render_to_response, it might be interested in the request, in the template at hand. An open question is, wether it should be allowed to override/replace the template. Of course then "context" is maybe the wrong namespace name.
Maybe pass in a RenderingContext object, which has the view_name, request, template, ... in it and the hook then can do render_ctxt.replace_template("plugin/new/template.html") when it wants to do so?

On the other hand, this all feels a bit over-engeneered and we tend to go small first and make things bigger when we need to.

[Christopher Allan Webber]

Thanks for the comments Elrond.

I'm not sure about filters=None to call for every render to response. It seems to me that for something like that, we could use a general "every render to response" render, and just continue to use hook names. However, I do like the idea of namespacing hooks for different types.

Regarding hook calling convention... the request gets passed into the context, and I think just passing the context with request into each method seems like it would be fine. If eventually we need to get more complex, we can do so then.

[Christopher Allan Webber]

Horray! This is done and merged. See the pluginwriter api documentation for details on the new hooks.