2010/10/15 Andy McCurdy <sed...@gmail.com>
> We are in complete agreement ;)
>
Thanks for the clarification ;)
>
> 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<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.
