Code

Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#12116 closed New feature (wontfix)

needs_context for template filters

Reported by: Suor Owned by: Suor
Component: Template system Version: master
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)

needs_context.diff (2.1 KB) - added by Suor 5 years ago.

Download all attachments as: .zip

Change History (11)

Changed 5 years ago by Suor

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests set
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

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 4 years ago by Alex

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 4 years ago by subsume

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

comment:4 Changed 4 years ago by Suor

  • Owner changed from nobody to Suor
  • Triage Stage changed from Accepted to 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 Changed 3 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:6 Changed 3 years ago by aaugustin

  • 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 3 years ago by Suor

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 3 years ago by aaugustin

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 3 years ago by aaugustin

  • Resolution set to wontfix
  • Status changed from new to 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 Changed 3 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.