On Fri, Oct 15, 2010 at 6:09 AM, Andrew Godwin <and...@aeracode.org> wrote:
> So, from what I can work out, this is a proposal for an {% extends %} tag
> which allows you to extend from the parent template of the same name (so it
> looks back in the list of possible templates, and picks the one that comes
> before yours, in your case inheriting from the admin version of the template
> with the same name?
>
> I'd like to know what sort of use cases you think this is necessary in - in
> the example you provide, admin/change_list.html, the recommended way of
> doing what you're doing would be to set change_list_template on the
> ModelAdmin class to point to a different template which itself inherits from
> admin/change_list.html, rather than having two with the same name, which
> could be potentially confusing.
At Whiskey, we have a custom extends tag that accomplishes the same thing --
the ability to extend templates of the same name. For a quick background, we
have a fairly large number of apps that we reuse on multiple sites. Each app
provides a set of templates with "sane default" functionality. We end up
customizing a fair number of these templates on a per-site basis to simply
add some additional context for users. For example, we have a generic forum
app. On our video game site, we've added our users' XBOX Live scores under
their usernames when displaying forum messages. This gives viewers an idea
how much the author actually knows about the game being discussed. We do
these kinds of things quite frequently.
We've named our custom extends tag "extends" and simply add it to the system
builtins. This way, all template extending goes through our tag.
We chose to use this custom extends method rather than the established "have
your view accept a template parameter, then manually specify the template
from the urls.py module" pattern for several reasons:
- We found having more template names was more confusing. Across all of our
apps, we already have close to 1,000 unique template names. Adding more for
these common customizations would lead to more confusion of our designers.
- Specifying overridden templates in urls.py leads to terrible looking URL
files. It's also a gross violation of DRY. Consider this example:
forums/urls.py:
------------------------------
...
url(r'topic/$', views.topic, name='forum-topic'),
...
site/urls.py
------------------
...
(r'fourms/$', include('forums.urls')),
...
Now if I want to override the template that displays a forum topic, I have
to not only include the forums.urls above, I also have to copy/paste the
forum-topic url into site/urls.py to simply add extra kwargs specifying the
template name to the view. This gets gross real quick:
site/urls.py
------------------
...
from forums import views
url(r'forums/topic/$', forum_views.topic, name='forum-topic',
kwargs={'template': 'overridden_template.html'}),
(r'fourms/$', include('forums.urls')),
...
- One or two of the 3rd party apps we use don't allow for template customize
through view kwargs. Since our tag is loaded as the default extends tag, we
can customize these templates for free without having to write any Python
code.
- Finally, I don't really want our designers in Python code if I can help
it. Even if it's just copy/pasting from one urls file to another. And I
certainly don't want to be asked every time they want to override a template
to make a 1 line change.
-andy
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
