I just thought of a better solution. Taglibraries are just like
templates:
- they get loaded from paths set in settings.py
- and else they get loaded by the template_loaders
IMHO we could do the same thing for taglibraries.
Rudolph
--~--~-~--~~~---~--~~
You rece
Maybe the error message should be a bit more informative. Instead of
telling the programmer the taglibrary isn't in django.templatetags, it
should tell the taglibrary is not found inside one of the
INSTALLED_APPS.
It would be cleaner if one could load taglibraries from every possible
location: it
On 4/26/06, James Bennett <[EMAIL PROTECTED]> wrote:
> But it's still magic, and it means that any given tag library can be
> imported from either of two locations -- its actual conventional
> Python path, and its "magic" location in 'django.templatetags'.
>
> So... should this bit of magic stay,
After trawling around the magic with James I have to say that I'm for this particular bit of magic. The alternative is to walk all subdirectories of INSTALLED_APPS and look for someting that looks like a taglibrary. I'm not sure if it can be done any more efficently, but I'm a little worried abou
I got bitten by ticket #1675 today, and took some time to work out
exactly what was going wrong. It turned out I was setting up my custom
tag library incorrectly, but the process revealed some magic that
magic-removal hasn't gotten rid of.
In looking at how the 'load' tag is implemented, I was co
