Extend inclusion tag syntax to allow custom templates

[exogen@…]

Currently, inclusion tags are not very reusable since they are bound to a template at registration time. For example, the only way to customize Djagno admin's change_list_results.html template is to ensure your template of the same name is found first. I propose extending the inclusion tag syntax so that all inclusion tags can be called like so:

{% show_results poll using "custom/results.html" %}

If the "using ..." part is omitted, the template specified during registration will be used. (The keyword decided upon, 'using' in this case, is not important.)

The only problem: this could break existing apps that use the keyword ('using' in this case) as a variable name. But we can make this behavior well-defined.

[exogen@…]

Initial version with with docs

[exogen@…]

Fixed typos in docs

[exogen@…]

Fixed diff whitespace, docs typos

[exogen@…]

allow_template_override is now allow_override

[(none)]

Milestone post-1.0 deleted

[Andrew Badr]

Even if you're willing to write multiple inclusion tags for some finite number of templates that take the same context, you have to write a wrapper around the context function. (Django won't let you use the same function for multiple inclusion tags.) One possible workaround might be to do {% with inclusion_template as 'whatever'%}{% show_result %}{% endwith %} and show_result would render a template that includes the inclusion_template that it gets from the context.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.