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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
