Django

Code

Ticket #1199 (assigned)

Opened 3 years ago

Last modified 4 months ago

Supporting more than one argument in a custom filter

Reported by: Aggelos Orfanakos Assigned to: insin (accepted)
Milestone: Component: Template system
Version: Keywords:
Cc: Triage Stage: Accepted
Has patch: 1 Needs documentation: 1
Needs tests: 1 Patch needs improvement: 0

Description

It would be nice to be able to pass more than one argument to a (custom) filter. E.g.: 

{{ value|custom_filter:arg1,arg2,arg3 }}

The only current workaround for this, that I have found, is passing a sequence (e.g. tuple, list) containing many arguments and then, inside the custom filter, do something like: 

def custom_filter(value, arg):
    arg1 = arg[0]
    arg2 = arg[1]

    # ...

Attachments

sprint-patch1.diff (3.9 kB) - added by insin on 09/15/07 15:14:16.
A first stab at just getting this working at all
ticket-1199.patch (3.9 kB) - added by Jan Rademaker <j.rademaker@gmail.com> on 04/03/08 15:57:42.
Updated insin's patch to revision 7397 + a bugfix

Change History

01/21/07 21:28:13 changed by SmileyChris

  • stage changed from Unreviewed to Design decision needed.

I don't know why this hasn't been already implemented. Perhaps if someone wrote a patch whether it'd speed things along. ;)

02/10/07 03:15:48 changed by anonymous

  • stage changed from Design decision needed to Accepted.

Currently, everywhere we need multiple arguments, we pass them in as comma-separated strings. However, this isn't perfect if you want a comma in your argument list.

So the idea seems reasonable. If somebody writes a patch (with tests), we'll look over it.

02/10/07 03:23:27 changed by mtredinnick

Last comment was from me. Sorry, accidently not logged in.

09/14/07 07:38:38 changed by lorien

  • owner changed from nobody to lorien.
  • status changed from new to assigned.

09/14/07 09:02:28 changed by lorien

  • owner deleted.
  • status changed from assigned to new.

09/15/07 15:14:16 changed by insin

  • attachment sprint-patch1.diff added.

A first stab at just getting this working at all

09/15/07 16:41:46 changed by insin

  • owner set to insin.
  • needs_docs set to 1.
  • has_patch set to 1.
  • status changed from new to assigned.
  • needs_tests set to 1.

(follow-up: ↓ 9 ) 01/11/08 22:27:25 changed by FogleBird 

Currently, everywhere we need multiple arguments, we pass them in as comma-separated strings. However, this isn't perfect if you want a comma in your argument list.

Also not perfect if your arguments aren't hard-coded, constant strings.

I ran into this limitation today and found this ticket. Are tests and documentation all that are holding this back? If so, perhaps now is a good time for me to make a contribution to Django. IMO, it's little things like these that make Django a pain sometimes (as much as I love it), so I'd like to help remove this limitation if possible.

01/31/08 22:18:17 changed by limeyd

I was wondering rather than a argument list wouldn't an optional dictionary then you'd have the best of both worlds?

(in reply to: ↑ 7 ) 02/01/08 01:14:09 changed by SmileyChris

Replying to FogleBird:

{{{ Currently, everywhere we need multiple arguments, we pass them in as comma-separated strings. However, this isn't perfect if you want a comma in your argument list. }}} Also not perfect if your arguments aren't hard-coded, constant strings. I ran into this limitation today and found this ticket. Are tests and documentation all that are holding this back? If so, perhaps now is a good time for me to make a contribution to Django. IMO, it's little things like these that make Django a pain sometimes (as much as I love it), so I'd like to help remove this limitation if possible.

02/01/08 01:14:27 changed by SmileyChris

Oops, lets try that again:

Replying to FogleBird:

If so, perhaps now is a good time for me to make a contribution to Django.

Foglebird - it's been accepted, so if you can help get the ticket closer to ready-for-checkin then start coding! Since the patch was described as "a first stab", I'd imagine that when you start the tests you may find some areas which need improvement on the patch. Drop into IRC and have a chat if you need any pointers for writing the tests / docs.

04/03/08 15:57:42 changed by Jan Rademaker <j.rademaker@gmail.com>

  • attachment ticket-1199.patch added.

Updated insin's patch to revision 7397 + a bugfix

04/03/08 16:00:11 changed by Jan Rademaker <j.rademaker@gmail.com>

The previous patch only worked for string literals, ticket-1199.patch should fix that (eg Variable(var_arg)).

07/27/08 11:42:02 changed by emulbreh

  • milestone set to post-1.0.

If whitespace handling will ever be relaxed (as in #7806), the proposed syntax will not work for {% url %} and similar tags that use ",". {% url view x|filter:a,b %} could mean (x|filter:(a,b)) or ((x|filter:a), b).

Syntax proposals:

  1. New syntax: foo|bar(x,y,z), keeping foo|bar:x for bc.
  2. Tupel primitives: foo|bar:(x,y,z), would allow {% for x in (a,b,c) %}
  3. Lisp style: foo|bar:(x|cons:y), this would basically allow bracketed expressions as arguments to filters. Arguably the ugliest.

The second and third option could either pass the tuple to the filter function, which would mean render-time argc checks, or pass *tuple as proposed in the current patch.

I favour the first option although tuple primitives seem useful. But that could easily be separate ticket.

09/16/08 18:14:39 changed by bbeck

I don't think the {% url %} issue above warrants avoiding a,b,c syntax, but I always imagined it might look like this: 

    foo|bar:x:y:z

10/27/08 07:30:31 changed by emulbreh

I would favour a syntax that allows filter expressions as arguments to filters. foo|bar:a:b|baz:c:d and foo|bar:a,b|baz:c,d cannot distinguish foo|bar(a, b|baz:c, d) and foo|bar(a, b|baz(c, d)).

02/25/09 13:51:44 changed by

  • milestone deleted.

Milestone post-1.0 deleted

Add/Change #1199 (Supporting more than one argument in a custom filter)




Change Properties
Action