Opened 9 years ago

Closed 9 years ago

#1586 closed enhancement (wontfix)

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

Reported by: mir@… Owned by: adrian
Component: Template system Version: magic-removal
Severity: minor Keywords: template loader
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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 ...

Attachments (2)

virtual_app_directories.diff (2.4 KB) - added by mir@… 9 years ago.
patch to add contrib.template_loader.virtual_app_directories
local_app_templates.diff (5.4 KB) - added by SmileyChris 7 years ago.
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…

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by mir@…

patch to add contrib.template_loader.virtual_app_directories

comment:1 Changed 9 years ago by anonymous

  • Component changed from Admin interface to Template system

comment:2 Changed 9 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:3 Changed 9 years ago by mir@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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?

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by 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.

comment:6 Changed 9 years ago by adrian

  • Resolution set to wontfix
  • Status changed from reopened to closed

Closing for the reasons Jacob pointed out.

Changed 7 years ago by SmileyChris

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...

Note: See TracTickets for help on using tickets.
Back to Top