Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#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


Would be great to do something like:

    import pytz
    from django.conf import settings
    from django import template
    register = template.Library()

    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)

needs_context.diff (2.1 KB) - added by Alexander Schepanovski 13 years ago.

Download all attachments as: .zip

Change History (11)

Changed 13 years ago by Alexander Schepanovski

Attachment: needs_context.diff added

comment:1 Changed 12 years ago by Russell Keith-Magee

Needs tests: set
Patch needs improvement: set
Triage Stage: UnreviewedAccepted

I don't see why needs_autoescape and needs_context have to be mutually exclusive, but otherwise, looks like a good idea.

comment:2 Changed 12 years ago by Alex Gaynor

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 Changed 12 years ago by Yeago

one nag. can we change this to 'takes_context' to fit with templatetag version.

comment:4 Changed 12 years ago by Alexander Schepanovski

Owner: changed from nobody to Alexander Schepanovski
Triage Stage: AcceptedDesign 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 Changed 11 years ago by Julien Phalip

Severity: Normal
Type: New feature

comment:6 Changed 11 years ago by Aymeric Augustin

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 Changed 11 years ago by Alexander Schepanovski

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 Changed 11 years ago by Aymeric Augustin

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 Changed 11 years ago by Aymeric Augustin

Resolution: wontfix
Status: newclosed

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 Changed 11 years ago by anonymous

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.

Note: See TracTickets for help on using tickets.
Back to Top