#625 closed defect (fixed)
[patch] Add template decorators
Reported by: | rjwittams | Owned by: | Adrian Holovaty |
---|---|---|---|
Component: | Template system | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
This patch includes two decorators for making template tags easier to create.
@simple_tag :
This one is for converting functions that return a string into template tags. eg.
definition:
@simple_tag def monkey_tag(verb): return "I %s no evil" % verb
use:
{% monkey_tag "hear"%}
arguments are resolved using template.resolve_variable -> ie currently limited to variable references and constant strings.
@inclusion_tag
This decorator turns a function returning a dictionary into a template tag that renders another template inline using that dictionary as the context. The decorator takes three arguments :
- path - required path to template
- context_class - kwarg to override the default context created
- takes_context - kwarg boolean. If true, the first argument of the function must be called 'context', and the context of the calling template will be passed into this argument. Useful if it is heavily context dependent and there would be a huge number of arguments.
The point of not just using the parent context is to make it easy to tell which context variables are used in which templates, ie avoid dynamic scoping hell.
eg:
@inclusion_tag('farming/cow_detail') def cow_display(cow): return { 'name': cow.name, 'similar': find_similar_cows(cow) }
template : 'farming/cow_detail'
<div> <h2>{{name}}</h2> <b> similar cows: </b> {%for cow in similar %} <p>{{cow.name}}</p> {% end for %} </div>
use:
{% cow_display cow %}
Attachments (2)
Change History (11)
by , 19 years ago
Attachment: | django-template-decorators.diff added |
---|
comment:1 by , 19 years ago
I'm not sure about the naming/location of the file. Seems like we have a lot of things called template_<something>... is that telling us something?
comment:2 by , 19 years ago
Description: | modified (diff) |
---|
comment:3 by , 19 years ago
Yeah, we should move template-related modules into a django.core.template
package, but that would be backwards-incompatible because a lot of code does from django.core.template_loader import ...
and from django.core.template import ...
.
comment:4 by , 19 years ago
Description: | modified (diff) |
---|
comment:5 by , 19 years ago
We could always have backwards compatibility for template_loader by just having
from template.loader import *
in template_loader.py . Keep that around for a while but deprecate it.
and django.core.template would still work as it would be in template/init.py
or am I missing something?
comment:6 by , 19 years ago
Nope, you're not missing anything. :) That would do it! I think we're safe to assume nobody will have used defaultfilters, defaulttags or template_file directly.
I'll open a separate ticket.
by , 19 years ago
Attachment: | django-template-decorators-2.diff added |
---|
updated patch, moved to template/decorators.py to fit in with template reorganisation
comment:8 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:9 by , 18 years ago
Type: | enhancement → defect |
---|
patch to add template decorators