In principle it's a DRY code of a template node that can be used for creating project-wide template-tags. These can be used to display conceptually common blocks in templates with applications specific looks and content. E.g.:
1. application-specific info message,
2. model instances details in the list context,
3. login messages like 'Please login or signup to [some app-dependent text]' with appropriate url's,
4. standard forms (e.g with same CSS classes, displayed with uni_form).
The code is profusely commented so look it up for details. Basically, when you have your project-wide `SubIncludeNode` tag defined, then just define appropriately named templates in applications template subdirectories e.g. `'profiles/_show_item.html'`.
** Example usage: login or signup message **
Let's say we are editing template rendered by the view indicated by the pattern named 'project_list' in the 'projects' app:
{# those are equivalent #}
{% login_or_signup %}
{% login_or_signup project_list %}
{% login_or_signup "project_list" %}
{# academic purposes direct sub_include usage #}
{# those two includes are also equivalent if there is no template called '_login_or_signup.html' in the 'projects' subdirectory #}
{% url acct_signup as signup_url %}
{% url acct_login as login_url %}
{% url project_list as next_url %}
{% sub_include "_login_or_signup.html" %}
{% include "_login_or_signup.html" %}
{# and those two are also equivalent if there is a template called '_login_or_signup.html' in the 'projects' subdirectory #}
{% sub_include "_login_or_signup.html" from "projects" %}
{% sub_include "_login_or_signup.html" %}
{# also equivalent include if there is no variable called 'projects' in tempalte's context #}
{% sub_include "_login_or_signup.html" from projects %}
{# those are examples of using custom subcontext #}
{% url acct_signup as signup_url %}
{% url acct_login as login_url %}
{% sub_include "_login_or_signup.html" from "default" with login_url,signup_url,next_url="/welcome" %}
{% sub_include "_login_or_signup.html" with login_url="/login",next_url="/welcome",signup_url="/signup" %}
** Mored advanced usage proposal **
Say you have an subclasses of some model from the original app in a separate extending apps. You want to display subclasses instances differently using the original app templates. In the original app you do not know what the set of subclasses is (as the original app is not aware of the extending apps). Subclassing the `SubIncludeNode` you can override the `default_subdir` method such that it returns the app label of a model instance that was passed as a argument of your tag. This way you just put templates like `_show_instance.html` in extending apps subdirectories and voila - you have implementation of the overrideable templates displaying appropriately details about the model subclass instances.
- templatetag
- templatetags
- include
I was looking for a way to save screen real estate, by using icons instead of labels for my list of choices, which in addition should be displayed as horizontal radio buttons.
For example, I wanted to use thumbs_up.gif instead of "approve".
I found a HorizontalRadioRenderer here:
[https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons](https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons)
Thanks to Barry McClendon for this snippet!
At first, I tried to achieve display of icons instead of labels by modifying the render method, but after a while I gave up on that and decided to just use the choices tuple.
This doesn't work too well with a select box (no icons, no text), but in combination with a radio widget it looks quite nice.
If you mark the strings for translation, you can also easily change icons, alt and title for each language.
- forms
- choices
- choicefield
- render
- radiobuttons
- icons