#2539 - Namespacing template tags and libraries

[Andrew Durdin]

Tick #2539 "Custom tags and filters can be restricted by namespace"
was one of the ones I was going to pick up during the django sprint,
but someone else beat me to it. However, the other day I noticed that
the patch against it was old, and admitted to be incomplete by its
author. Since namespacing of tags and libraries is such a honking
great idea :) -- and something I've wanted for quite some time, I
decided to put a complete patch together for it.

The patch adds a few tests and docs; the idea has already been
approved by Adrian, so it just needs a review from someone not me to
say if it's ready for checkin or not.

The patch is described in detail on the ticket, but here's an extract:

All tag libraries have an associated fully qualified name, which looks
like "app_name.tag_library_name"; this fully qualified name can be
used instead of the unqualified library_name in the {% load %} tag:

Normally we'd do

{% load humanize %}

But if another installed app has a 'humanize' tag libary, we might need to do

{% load django.contrib.humanize.humanize %}

If more than one installed app has a tag library with the same name,
then the app closest to the start of the INSTALLED_APPS list will take
precedence if the unqualified name is used.

Correspondingly, templatetags and filters are also namespaced -- by
the name of the tag library as given to {% load %}. So you can do
this:

{% load library %}
{% load otherapp.library %}

{% library.mytag %} # Outputs "A"
{% otherapp.library.mytag %} # Outputs "B"

But not this:

{% load firstapp.library %}
{% library.mytag %} # We've not loaded anything as 'library'

Cheers,

A.

[doug.na...@gmail.com]

Selfishly I would like to be able to do:
{% load firstapp.library as mylib %}
{{ context_var|mylib.myfilter }}

To cut down on the typing and make things a bit more DRY.

Granted this gets very close to python import syntax, and begins to
look like python in a template, something which I do not like.
For clarity:
While it looks like the next logical step, I would not want to see:
{% from django.contrib.humanize.humanize load currency %}
{{ bill.total|currency }}

(yes, that is a strawman... sorry).

-Doug

[Andrew Durdin]

On 10/21/07, doug.na...@gmail.com <doug.na...@gmail.com> wrote:
>
> Selfishly I would like to be able to do:
> {% load firstapp.library as mylib %}
> {{ context_var|mylib.myfilter }}

I don't think this would play nicely with the existing {% load
library1 library2 %} syntax.

A.

[doug.na...@gmail.com]

On Oct 22, 8:50 am, "Andrew Durdin" <adur...@gmail.com> wrote:

> On 10/21/07, doug.napole...@gmail.com <doug.napole...@gmail.com> wrote:
>
>
>
> > Selfishly I would like to be able to do:
> > {% load firstapp.library as mylib %}
> > {{ context_var|mylib.myfilter }}
>
> I don't think this would play nicely with the existing {% load
> library1 library2 %} syntax.

Rats, forgot about that one.. nevermind.

-Doug

[Bruce Kroeze]

Why couldn't both coexist, but be mutually exclusive?

{% load firstapp.library as mylib %}

{% load thislib thatlib theotherlib %}

The only thing that would prevent is the use of a library named "as" loaded in the second position, not a big deal.  After all, we are already using "as" all over the place in template tags and it would be a logical, convenient extension of that idea.

[Andrew Durdin]

On 10/23/07, Bruce Kroeze <bkr...@gmail.com> wrote:
> Why couldn't both coexist, but be mutually exclusive?
>
> {% load firstapp.library as mylib %}
> {% load thislib thatlib theotherlib %}

They could; it would certainly be convenient, and a simple change to
implement, but at the expense of a slight loss in clarity of the load
tag.

I think it's a good idea, but I'm not going to add it into the
ticket/patch unless it gets the ok from one of the core devs.

A.