#2539: Custom tags and filters can be restricted by namespace
---------------------------------+------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: anonymous
Status: assigned | Component: Template system
Version: | Resolution:
Keywords: | Stage: Accepted
Has_patch: 1 | Needs_docs: 1
Needs_tests: 0 | Needs_better_patch: 0
---------------------------------+------------------------------------------
Changes (by durdinator):
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
Comment:
OK, this looks like it's stagnating, and it's something I definitely want.
So here's a patch against [6507]. It's not based on limodou's or racter's
work, and is more comprehensive in what it tidies up. Here's a summary of
the result:
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'
}}}
If there is a conflict in tag names, then the last loaded tag library
takes precedence (the same as the behaviour in trunk in such a case).
All that applies to tags also applies to filters, of course.
The standard django tag libraries can be accessed via their fully
qualified names "django.defaulttags", "django.defaultfilters",
"django.loader_tags", and "django.i18n".
Possible backward-incompatible changes (not sure if any of these changed
interfaces were intended to be publically used):
* The items of django.template.libraries and django.template.builtins are
now tuples, not Library instances.
* Template.add_library and django.template.add_to_builtins require
additional arguments.
* The django.templatetags package no longer augments its __path__ with
from all installed apps' "templatetags" packages -- instead it is limited
to the standard set of django tags.
A definite (though doubtless rare) backward-incompatible change:
* `{% load foo.bar %}` will load from `foo<app>.templatetags.bar` in
preference to `<some_app>.templatetags.foo.bar`.
Final notes:
The django and contrib tests that used template.libraries and/or
add_to_builtins have been updated, so they should still pass (I've not
checked the humanize or markup tests though).
The admin docs has been updated to list all tag libraries available, and
list the fully qualified name alongside the unqualified name.
And I still need to modify the documentation to accommodate these changes,
but I'll do that in another patch, because it's getting late.
--
Ticket URL: <http://code.djangoproject.com/ticket/2539#comment:20>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
