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.
