about templatetag namespaces

16 views
Skip to first unread message

Amit Upadhyay

unread,
Jul 10, 2008, 11:08:39 AM7/10/08
to django-d...@googlegroups.com
Hi,

I have identified a few issues over the time that makes working with custom django template tags/filters a little less than ideal for me.

My chief problem is: if I see an unknown/unfamiliar tag/filter and want to locate the exact code responsible, I have to do the following: find all loads defined in the template, for each of those "loaded template libraries", I have to find the py file by searching it in all INSTALLED_APPS/templatetags folder and then scanning them for a register_tag/register_filter call with the unknown name. This to me is a little bit too much magical[PS1]. Further, what if there are more than one apps with some_template.py in their templatetags folder? And why is it called templatetags when it can have both filters and tags? (*tongue in cheek remark :-).

Bottom line is clean namespacing is difficult to achieve as of now, but would be possible with the following "syntax":

{% load mytemplatelib.few_tags as cool_tags %}

and used subsequently as {% cool_tags.show_something %}. Or the alternate syntax:

{% load mytemplatelib.few_tags.* %} and I can do {% show_something %} [this sytax would come with its warning similar to the ones issued against using the "from django import *" like imports in python].

Note: mytemplatelib.few_tags would be search in sys.path and not in installed_apps' templatetags folders.

As a template writer I will have to provide a module mytemplatelib.few_tags with a show_something named function which acts as a tag. There would be some decorators/protocol to tell if they are valid tag/filter.

Assuming the idea is accepted, It can be implemented in a mostly backward compatible fashion, post 1.0, either by having a {% import %} named new loader for 1.x, or even {% load %} name can be preserved as one can first look into the old way of loading and if it fails can look for new way.

This has been discussed before[1], but I have some objections with the latest implementation[2]:
* appname/templatetags still persist, and is the place where libraries will be looked into, there is no reason for django to enforce and create its own import paths, PYTHONPATH, sys.path etc are good enough for that. Let application developers and templatetags library writer pick what makes sense. Looking into INSTALLED_APPS constraint does not buy much and can be cleaned up entirely.
* We still have to do the search if we get a new/unfamiliar template tag/filter. This is just not pythonic to me.

Both these are backward incompatible changes, but like I said current way can be kept, with some DepricationWarning, and 1.x may include the new way which looks for module name in sys.path instead of app_name/templatetags/.

Subproposal:

Add settings: DEFAULT_TEMPLATE_EXTENSIONS [avoiding the words tags/filter as it can be either], being a list of strings that will be automatically be {% load whatever %} in all templeates.

Subsubproposal:

Split defaulttags into defaulttags_essentials which will include tags like "load", "extends", "block" etc, which are really required for templates to work vs others like "for"/"if" and the rest into some other module that gets added by default in "settings.DEFAULT_TEMPLATE_EXTENSION". So that if I can use the fancier versions of my template tags/filters by turning off the django ones and using just mine, without having to use any namespace prefix, and without having to worry abt conflicts with django's default template tags/filters.

PS1: Though there is nothing stopping me from writing a script that takes the tag/fitler name and returns me the qualified name of the function handling the tag/filter.
[1]: http://groups.google.com/group/django-developers/browse_frm/thread/2b5a4a31f0349d27/b92c96a8dccc214b#b92c96a8dccc214b
[2]: http://code.djangoproject.com/attachment/ticket/2539/patch_2539_code_tests.diff

--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512

Phil Davis

unread,
Jul 10, 2008, 4:13:23 PM7/10/08
to django-d...@googlegroups.com
2008/7/10 Amit Upadhyay <upad...@gmail.com>:
[...]

> This has been discussed before[1], but I have some objections with the
> latest implementation[2]:
> * appname/templatetags still persist, and is the place where libraries will
> be looked into, there is no reason for django to enforce and create its own
> import paths, PYTHONPATH, sys.path etc are good enough for that. Let
> application developers and templatetags library writer pick what makes
> sense. Looking into INSTALLED_APPS constraint does not buy much and can be
> cleaned up entirely.

One thing I like about Django is the template language is safe to let
non-python coders loose with. If you directly allow template authors
to start playing with python package names you are breaking this
separation down. It will also IMHO make apps more fragile when moving
between systems with different python packages available or at least
make tracking down version mismatches more difficult.

So I think django has a very *good* reason to only look in
INSTALLED_APPS/templatetags.

If you really need the functionality just write a small app which
contains a new template tag, say 'import' which works as you want.

Cheers,

--
Phil Davis

Rajeev J Sebastian

unread,
Jul 10, 2008, 5:48:49 PM7/10/08
to django-d...@googlegroups.com
Hi Amit,

On Thu, Jul 10, 2008 at 6:08 PM, Amit Upadhyay <upad...@gmail.com> wrote:
> or even {% load %} name can be preserved as one can first
> look into the old way of loading and if it fails can look for new way.

I've done this in my company's mercurial repo of django. It works
well, and allows us to create template/filter libraries independent of
any application.

Right now, we use it to collect a lot of the django snippets together
into a library.

Regards
Rajeev J Sebastian

Johannes Dollinger

unread,
Jul 11, 2008, 8:45:45 AM7/11/08
to django-d...@googlegroups.com
+1 for the main proposal and subproposal (modulo concrete syntax).
Decoupling template library imports from app_label would also be good
for #3591. Get rid of as many app_label dependencies as possible.
Beautiful languages such as php and c have flat namespaces - don't go
there.
Concerning your subsubproposal: strictly only {% load %} would be
essential. So the separation would be mostly arbitrary. Just allow
libraries to shadow existing tags/filters.

(For those dismissing django.template features because of non-
programmer/designer/beginner use-cases: there already are quite a few
possibilities to shoot yourself in the foot, and I'd bet the template
language is turing complete.)

Malcolm Tredinnick

unread,
Jul 11, 2008, 9:08:37 AM7/11/08
to django-d...@googlegroups.com

On Thu, 2008-07-10 at 20:38 +0530, Amit Upadhyay wrote:
> Hi,
>
> I have identified a few issues over the time that makes working with
> custom django template tags/filters a little less than ideal for me.
>
> My chief problem is: if I see an unknown/unfamiliar tag/filter and
> want to locate the exact code responsible, I have to do the following:
> find all loads defined in the template, for each of those "loaded
> template libraries", I have to find the py file by searching it in all
> INSTALLED_APPS/templatetags folder and then scanning them for a
> register_tag/register_filter call with the unknown name. This to me is
> a little bit too much magical[PS1].

I'm -1 on both of these proposals. They're not really solving problems
that are big issues at the moment (having to do a grep through a couple
of files every now and again is hardly a showstopper and if it really
is, encourage your template designers to use comments to indicate which
tags they are using from which files).

Certainly implement the namespacing idea referred to in the thread that
you referenced, but make it fully backwards compatible so that existing
templates still work. That seems like a solution to a lot of the things
you're talking. Trying to pull Python's whole import infrastructure into
templates seems like overkill, however. Things just aren't going to get
complicated enough to justify it.

Malcolm

Reply all
Reply to author
Forward
0 new messages