#21367 closed New feature (wontfix)

Add new "split" filter in built-in library

Reported by: zuck Owned by: nobody
Component: Template system Version: master
Severity: Normal Keywords: string split filter
Cc: bmispelon@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I propose to add a very simple (but useful) filter to the Built-In library to split a string, giving a separator.

It's use is quite straight-forward:

{{ value|split:"/" }}

And this is a possible implementation:

@register.filter
@stringfilter
def split(string, sep):
    """Return the string split by sep.

    Example usage: {{ value|split:"/" }}
    """
    return string.split(sep)

Change History (5)

comment:1 Changed 22 months ago by bmispelon

  • Cc bmispelon@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Hi,

I don't really see the appeal of doing {{ value|split:"/" }} (you're just getting the string representation of the resulting list which is of little use).
Do you have a more realistic use-case for your proposed template tag?

Thanks

comment:2 Changed 22 months ago by zuck

Actually, you're getting a real list of split tokens.

i.e. Simple breadcrumbs

<ul class="breadcrumbs">
    {% for token in  request.get_full_path|split:"/" %}
    {% if token %}
    <li><a href="#">{{ token }}</a></li>
    {% endif %}
    {% endfor %}
</ul>

Also another, more complex, use case:

i.e. File extension checking (for CSS purposes)

<ul class="dir">
    {% for filename in filenames_list %}
    <li class="{{ filename|split:'/'|last|split:'.'|last }}">{{ filename }}</li>
    {% endfor %}
</ul>

i.e. Generate a list from arbitrary context data

{% with my_list=""|add:var1|add:sep|add:var2|add:sep|add:var3|split:sep %}
...
{% endwith %}

It creates a list, called "my_list", from var1, var2, var3.

In general, I think the current built-in library lacks of support to content "manipulation/formatting". Often we already have the data we need in the context, but we can't format it according to our needs due to the lack of basic data-manipulation/formatting filters and templatetags.

At the moment we have to code again and again these snippets or populate the context (in he view) with template-specific (and verbose) variables, which is not a big deal for view - template decoupling.

Last edited 22 months ago by zuck (previous) (diff)

comment:3 Changed 22 months ago by mjtamlyn

I don't find any of those examples convincing, especially the last one. That seems to me to be precisely the sort of thing you should not do in a template.

comment:4 Changed 22 months ago by zuck

  • Why don't you find any of these examples convincing, exactly?
  • Why do you think this is a not good practice in template?

First of all, the examples show simply data formatting and presenting, which is exactly the purpose of Django's template system.

Secondly, of course the last example is not ideal (it's hard to read and understand at first sight) but I posted it to show how this elementary filter could be used to do very complex things.

comment:5 Changed 22 months ago by russellm

  • Resolution set to wontfix
  • Status changed from new to closed

I agree with @mjtamyln and @bmispelon. There's a fine line between formatting logic and template logic; for me, this falls on the "template logic" side. If you've got something complex that needs to be split into parts for rendering purposes, you should be setting that up in the context, or using a custom template tag, not doing the parsing in a template. From the examples your provide:

  1. Breadcrumbs should be parsed before they get to the template. Interpreting a forward slash format in template logic is asking for trouble -- for example, this approach will break where the breadcrumb is called "input/output".
  2. Turning file extensions into class names is something that a custom template tag should be used for.
  3. Generating a list in a template is… not something I'd want to encourage. Demonstrating how elementary filters can be combined to do complex things is undeniable, but that doesn't mean we should be encouraging this behavior. Django templates are *not* a fully featured programming language, by design.

Marking this ticket as wontfix; if you are particularly enthusiastic about this proposal, please open a thread on django-developers and make your case. A ticket isn't the best place to have this sort of detailed discussion because it doesn't have the full attention of the developer community.

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