We are in complete agreement ;) 2010/10/15 J. Pablo Martín Cobos <goi...@gmail.com>
> Hi Andrew, > > I think you agree with me in all. Thank you very much for your long e-mail. > I think you have explain the problem better than me. To use the urls for > overwrite the templates "leads terrible looking URL", it's really true. > > If you don't think you agree with me in all, please tell me. Because as my > english is not very good I don't know if I have understand you perfect. > > -- > Pablo Martín > > 2010/10/15 Andy McCurdy <sed...@gmail.com> > >> >> 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<django-developers%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- > 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<django-developers%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- 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.