[patch] cooler version of django.template.loaders.app_directories

[mir@…]

The provided app_directories template loader is a bit uncool: To separate applications, you need to put your templates in subdirectories like this:

app1/templates/app1/index.html
app2/templates/app2/index.html

... so that you can load them as "app1/index" respective "app2/index"

I changed this a bit and created a new template loader that works like this:
If you request to load template "app1/index", it goes through all applications with label "app1" that have a "templates" subdirectory. It strips the application label off and tries to find the rest in the templates subdirectory. As a result, "app1/index" finds ".../app1/templats/index.html".

I suggest to put this in the contributions as django.contrib.template_loader.virtual_app_directories, but wouldn't mind a better name ...

[mir@…]

patch to add contrib.template_loader.virtual_app_directories

[Jacob]

This makes finding templates pretty confusing, and also removes the ability for one installed app to override templates from another. It's an interesting idea, and one you probably should add to the wiki somewhere, but doesn't seem to be something we should include in Django propper.

[mir@…]

I only reopened to get your attention, feel free to close if you're still against it ... that'll be that then.

I wouldn't mind if you said that you simply weren't interested and there are more pressing things on your mind.

Though, I'm confused about what you wrote. How does this make "finding templates confusing"? You know which app it is from, voila, there it is. The original loader makes it much harder to find the actual place of a template.

You can still overwrite templates if you must--in the example above, you could use the directory based template loader, set up directories '/templates/app1/index' or so, and if you put the directory based loader first, it will find the overwriting template first.

Note that I don't want to replace the original loader--this is an addition. Isn't 'contrib' the place for such user contributed stuff that doesn't really belong into the core?

[Jacob]

Sorry, that was a pretty terse explanation.

What I mean by "confusing" is that right now if I look at my view and I see loader.get_template("foo/bar"), I know I'm looking for a template named "foo/bar" on my search path somewhere. This change makes it into "look for a template named 'foo/bar' on the search path, but only if the app that the view is in isn't named 'foo'".

On top of that, this couples application names to templates -- if you change your application name, all of a sudden templates that used to be found correctly won't be. I really don't like the "hiddenness" of the search path, and I'm fine and dandy with having to create another template directory to make the search paths explicit.

As for contrib.... I'm not sure we've exactly figured out what the criteria for inclusion in "contrib" is yet :) So... I guess I'll leave this open while we come up with a reason why something of this nature should or should not be included in contrib.

[mir@…]

Now I can see what you meant, and your experience with Django is--ehemm--a lot deeper than mine.

I'm not offended at all if you close it, it was just hard to see your reasoning.

[Adrian Holovaty]

Closing for the reasons Jacob pointed out.

[Chris Beaven]

Just for kicks, I made a similar template loader to this (without even checking for an existing ticket) -- thought I may as well put it up here...