#12116 closed New feature (wontfix)
needs_context for template filters
Reported by: | Alexander Schepanovski | Owned by: | Alexander Schepanovski |
---|---|---|---|
Component: | Template system | Version: | dev |
Severity: | Normal | Keywords: | template filters, context |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Would be great to do something like:
import pytz from django.conf import settings from django import template register = template.Library() @register.filter def localtime(dt, context=None): if dt.tzinfo is None: dt = pytz.timezone(settings.TIME_ZONE).localize(dt) return dt.astimezone(context['timezone']) localtime.needs_context = True
Attachments (1)
Change History (11)
by , 15 years ago
Attachment: | needs_context.diff added |
---|
comment:1 by , 15 years ago
Needs tests: | set |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 15 years ago
I'm opposed to this, to me a template filter is extraordinarily well defined around taking input, and maybe an argument, and operating on those.
comment:3 by , 15 years ago
one nag. can we change this to 'takes_context' to fit with templatetag version.
comment:4 by , 14 years ago
Owner: | changed from | to
---|---|
Triage Stage: | Accepted → Design decision needed |
The value of autoescape parameter is always equal to context.autoescape, so there is no need in passing both. Still I don't mind updating patch to support this. Or docs to not support.
The name 'needs_context' corresponds to 'needs_autoescape' filter property. So some missfit is unavoidable.
Both are kind of design issues
comment:5 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
comment:6 by , 13 years ago
Easy pickings: | unset |
---|---|
UI/UX: | unset |
I'm going to implement a filter similar to your example as part of my work on #2626. We can't add an example that duplicates a core functionality, so we'll have to give another example if my work on #2626 is merged. Do you have other use cases for needs_context
?
If there isn't another compelling use case, like Alex, I'd prefer to keep the filters "contextless", for the sake of simplicity.
comment:7 by , 13 years ago
Datetime timezoning use-case I solved for myself with a custom model field which transforms
its value to user timezone when gets it from db. I also have form field which adds tz info
to datetimes received from user. This two work pretty well, I haven't need to bother
about timezones since I started using them. If you are interested I can push my solution
to github in a few days.
About other use-cases, there were some. One was about rendering forms to separate templates
with a |render filter, other was about url construction depending on host in request which
was in the context. First one will be probably appropriately done with template tags.
Second looks better as filter for me.
I can be biased, though. I really don't like custom tags not created to extend template logic
(some fancy loop or another control structure) but to add some application specific
rendering, because it means that we get rendering (template) logic in our application code,
which is MVC violation.
comment:8 by , 13 years ago
I still think filters with arguments or templatetags are the way to go for your examples.
Django isn't strongly committed to a MVC model, and in the end, "practicality beats purity".
comment:9 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Florian Apolloner added on IRC that if we give access to the context, we allow users to alter the context in filters, which means the filters can have side effects.
comment:10 by , 13 years ago
Side effects? What about "practicality beats purity"? But since I migrated to jinja2 I don't care about this feature anymore, and since nobody cares just dropping it seems okay.
As for the big picture django templates don't feel either practical nor convenient, they feel like chains on your arms.
And custom templatetags make your templates less customizable, inheritable and all. Look at django.contrib.admin templates for example.
I don't see why needs_autoescape and needs_context have to be mutually exclusive, but otherwise, looks like a good idea.