Add new "split" filter in built-in library

[Emanuele Bertoldi]

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)

[Baptiste Mispelon]

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

[Emanuele Bertoldi]

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.

[Marc Tamlyn]

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.

[Emanuele Bertoldi]

• 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.

[Russell Keith-Magee]

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.