Vinay Sajip wrote:
> On Dec 7, 6:35 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
>> On Dec 7, 2007 12:56 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>>
>>> this be allowed/disallowed/checked for? As for standard template
>>> loading, there's no reason that the standard template loading
>>> (app_loader) code could not be modified to work with App instances,
>>> using whatever logic to use the application path and/or label to
>>> locate the templates. Or have I misunderstood Malcolm's comment?
>> The problem here is that a distributed app has to expect specific
>> paths to its templates, both for its views (for render_to_response,
>> for instance) and its templates (for extends and include). If my
>> template says "{% extend 'modular/module.html %}', what would happen
>> if someone had "App('modular', name='mod_app')"? How would the extends
>> tag be able to locate the correct template if someone essentially
>> renamed the app?
>>
>
> The current code in django/template/loaders/app_directories.py appears
> to search in the directory 'templates' relative to the directory
> containing the app module. I can't quite see why this needs to change:
> it's independent of the app label, shouldn't that be OK?
It does look in the "templates" directory of the application directory;
however, it gets treated as a standard, global template directory. Current
practice is to repeat the name of your application inside the "templates"
directory to avoid name collisions. For example:
myblogapp/templates/myblogapp/base.html
So even if you were to specify an app_label of "blog" for this app, you would
still have to reference the templates as "myblogapp/base.html".
The current app_directories template loader has always bugged me because it is:
1) inefficient - all application template directories are added as global
template directories and are searched each time by the template loader.
2) unpredictable - any application could, unbeknownst to the developer,
override another application's templates. For example, an application could
include an "admin" directory in its "templates" directory that overrides admin
templates.
3) not DRY - just silly I have to make my "templates" directory one level
deeper with a duplicated name.
For those of you that have stopped using the app_directories loader in favor
of the standard filesystem loader and TEMPLATE_DIRS, what was your reasoning
behind doing so?
And doesn't doing things this was cause the same problems? Every directory
added is going to get searched as a global template directory. You're still
going to have the unpredictability of apps possibly overriding templates of
other apps. You are still going to be repeating yourself by having to put the
app in INSTALLED_APPS and its template directory in TEMPLATE_DIRS.
I have always thought that you should be able to put an app's templates in its
"templates" directory and that those templates should only be accessible when
using the app name in front of it, like "myblogapp/base.html". The
"myblogapp/templates" directory should not be looked at in any other case, and
only global template directories are looked at every time by the filesystem
template loader.
This should also work with custom app_naming, since now the templates would be
accessible with the custom name, i.e. "blog/base.html". This would also work
if you had two instances of an app running under two different names, i.e.
"blog1/base.html" and "blog2/base.html". And I could still override these in
a global template directory with directories named "blog1" and "blog2".
Gary
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
