On Sat, 2008-12-13 at 18:13 -0800, ptone wrote: [...] > So was modifying tutorial to use the app_directories loader > > Had to take out the 'polls/' subdir part of the template path - that > made sense.
No, you didn't have to do that. It's optional and, in this case, is the cause of your later problems. There's a conceptual thing to realise here: all of the <app_name>/template/ directories are merged into a single top-level namespace, when viewed from the perspective of the app_directories template loader. So if you put my_template.html into that directory for appA and are using another app that has the same template name in its template/ directory, you get a name collision and it's going to appear very random as to which template is loaded. So, it turns out to be useful practice to namespace the template hierarchy under the template/ directory for a lot of situations. Thus, <app_name>/template/<app_name>/* is not an uncommon layout to see. You don't necessarily need to put everything under that subdirectory (see below), but you need to understand when and why you're making trade-offs if you don't. > > Working just fine till I get into the part on generic views - out of > the box they seem to be generally incompatable with the app_dirs > loader. Incompatible is probably too strong a word - less automatic. > > As stated in the docs for generic views: > "If template_name isn't specified, this view will use the template > <app_label>/<model_name>_detail.html by default." > so if I have a template named: > > "poll_detail.html" > > I can't have it in project/polls/templates/poll_detail.html > > as would be expected for the app_dirs loader, Under your expectation that everything should go under the template/ directory, that seems like a big problem. However, there's a bigger picture. Like so many APIs, a lot of the default behaviour is built around historical and common usage, which doesn't necessarily match up with everybody's intuition or first expectation. Providing that the API's assumptions aren't completely counter-productive, this isn't typically a real problem in the long-term. It's easy enough to adjust. Use the my_app/templates/my_app/poll_details.html layout for this case. Here's the background logic: For model-specific templates like this, the namespacing makes a lot of sense. It is very easy to choose a model name that is used in another application you're using. Common nouns tend to be chosen... well.. commonly and duplication happens. However, your app_name must be unique, so this provides an effective namespace technique -- the template I want to use by default is the one that is specifically created for my model called "Poll", not the template that somebody else might have created for their model called "Poll" in another application. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
