Re: Smart extends

[J . Pablo Martín Cobos]

Hi SmileChris and Lukasz:

It's true that with this proposal the load of templates depends of the order
of on which the templates are loaded. But it's is something that the project
manager should controlled. But the usual is that you only overwrite only one
time a template (although it work with any number of overwrites).

2010/10/15 Łukasz Rekucki 

> 2010/10/15 J. Pablo Martín Cobos :
> >
> > Really the problem comes when we reuse a application: from other people,
> > from Django (i.e. django.contrib.admin), or even my own that we reuse in
> > some projects. Usually you want to change slight things and usually you
> want
> > only to change the visualization mode, you want to change the templates.
> You
> > need to adapt the application to your project.
> >
>
> It's a pretty good use case.


Thanks for your appreciation


> But there's a problem with your original
> proposal: the admin provides a default "x.html" . Then you have some
> 3rd party application "A" that enhances the "x.html". And now comes
> your application "B" that also wants to extend "x.html". So you write:
>
> {% extends "x.html" %}
>
> Which "x.html" should be chosen ? the one from admin or the one from
> external app "A" ? Both are valid uses. There is a dangerous
> temptation to say "next that would be loaded after this", but that
> depends on loaders and application order  - lets don't go that way.
>
>
This is a case that I didn't have studied. It's posible that it work
perfect, but if it don't work I have work for this week :-P

This is a work that I thought that I have finished today, but it's posible
that I need to work with this some more.

But I want to know your opinion, and I am happy that some developers thinks
that this is a good idea.


> Instead, IMHO, a good way to do this would be verbose about from which
> application you want the template to be loaded:
>
> {% extends admin:"x.html" %} # extend x.html from admin
> {% extends A:"x.html" %} #  extend x.html from application A
>
> Unfortunately for this approach, templates aren't provided or bound to
> applications - they're provided by loaders. It might be a good idea to
> extend the loader protocol to me "namespace" aware.
>
> My 2cents.
>
> --
> Łukasz Rekucki
>
> --
> 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.
>
>
Regards,

--

Pablo Martín

-- 
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.

Re: Smart extends

[J . Pablo Martín Cobos]

2010/10/15 Andy McCurdy 

> We are in complete agreement ;)
>

Thanks for the clarification ;)


>
> 2010/10/15 J. Pablo Martín Cobos 
>
>> 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 
>>
>>>
>>> On Fri, Oct 15, 2010 at 6:09 AM, Andrew Godwin 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.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this 

Re: Smart extends

[SmileyChris]

On Oct 16, 8:35 am, Łukasz Rekucki  wrote:
> Which "x.html" should be chosen ? the one from admin or the one from
> external app "A" ? Both are valid uses. There is a dangerous
> temptation to say "next that would be loaded after this", but that
> depends on loaders and application order  - lets don't go that way.

But this is exactly how templates are decided on currently. This does
introduce somewhat of a dependency on this load order to know what
template you are actually extending, but I don't really see a problem
with this.

-- 
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.

Re: Smart extends

[Andy McCurdy]

We are in complete agreement ;)

2010/10/15 J. Pablo Martín Cobos 

> 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 
>
>>
>> On Fri, Oct 15, 2010 at 6:09 AM, Andrew Godwin 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.
>>
>
>  --
> 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 

Re: Smart extends

[Andy McCurdy]

2010/10/15 Łukasz Rekucki 

> 2010/10/15 J. Pablo Martín Cobos :
> >
> > Really the problem comes when we reuse a application: from other people,
> > from Django (i.e. django.contrib.admin), or even my own that we reuse in
> > some projects. Usually you want to change slight things and usually you
> want
> > only to change the visualization mode, you want to change the templates.
> You
> > need to adapt the application to your project.
> >
>
> It's a pretty good use case. But there's a problem with your original
> proposal: the admin provides a default "x.html" . Then you have some
> 3rd party application "A" that enhances the "x.html". And now comes
> your application "B" that also wants to extend "x.html". So you write:
>
> {% extends "x.html" %}
>
> Which "x.html" should be chosen ? the one from admin or the one from
> external app "A" ? Both are valid uses. There is a dangerous
> temptation to say "next that would be loaded after this", but that
> depends on loaders and application order  - lets don't go that way.
>
> Instead, IMHO, a good way to do this would be verbose about from which
> application you want the template to be loaded:
>
> {% extends admin:"x.html" %} # extend x.html from admin
> {% extends A:"x.html" %} #  extend x.html from application A
>
> Unfortunately for this approach, templates aren't provided or bound to
> applications - they're provided by loaders. It might be a good idea to
> extend the loader protocol to me "namespace" aware.
>
> My 2cents.
>
>
Ya, if you're using the AppDirectory loader already, you get this for free.
Of course if Django were to accept this, it would need to work with all the
loaders. For our implementation, we've made our own template loader
subclasses the AppDirectory one.

-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.

Re: Smart extends

[SmileyChris]

On Oct 16, 2:09 am, Andrew Godwin  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

Just to chime in, I like this proposal.

IMO: If a designer wants to override a third party's template (by
altering blocks), they should not have to:
1. copy paste the template
2. touch python code

Admin's solution is only works when presented with foreknown
hierarchical data.
The solution of apps needing to provide a way to override default
templates (usually via a view argument) is a cumbersome requirement
app developers and requires (2).
http://code.djangoproject.com/wiki/ExtendingTemplates doesn't really
work for third party apps that well.

One downer is that this makes the behaviour of templates with self-
extending tags dependent on the order on which the templates are
loaded.

-- 
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.

Re: Smart extends

[J . Pablo Martín Cobos]

Hi Dougal,

Of course this have many advantages for front end developers and designers.
But please we must not do "full copy and paste of the original template".
This is the finallity of the project.

The template code is nearly so important as view code.

Regards,

--

Pablo Martín

2010/10/15 Dougal Matthews 

> I can see one main use case. Front end developers and designers would be
> able to extend templates without worrying about python code changes or doing
> a full copy and paste of the original template (if they can find it.)
>
> Dougal
>  On 15 Oct 2010 14:10, "Andrew Godwin"  wrote:
> > On 15/10/10 13:41, J. Pablo Martín Cobos wrote:
> >> Hi,
> >>
> >> I'm a Django developer since more or less 3 years. Some time ago I had
> >> the need for the extends templatetag to have more funcionality.
> >>
> >> The funcionality I mean is that a template can extends from "itself".
> >> I'm going to try to explain it better, so I will put Django admin as
> >> an example, although I needed it in others places. In many projects I
> >> wanted to customize the admin site, I wanted to tiny modify the
> >> change_list template or the change_form template, etc. I.E. like the
> >> following:
> >>
> >> file:templates/admin/change_list.html
> >>
> >> {% extends "admin/change_list.html" %}
> >>
> >> {% block extrastyle %}
> >> {{ block.super }}
> >> 
> >> {% endblock %}
> >>
> >>
> >> {% block breadcrumbs %}
> >> 
> >> 
> >> {% trans "My Project" %}
> >> 
> >> 
> >> 
> >> {{ app_label|capfirst }}
> >> 
> >> 
> >> {{ cl.opts.verbose_name_plural|capfirst }}
> >> 
> >> {% endblock %}
> >>
> >>
> >> To perform something like this, we should copy all the change_list
> >> template (i.e. 100 lines of code), in order to add this two changes.
> >> For this subject I created a google-code project [1], wich is working
> >> in a little project of Universidad de Granada [2] succesfully.
> >>
> >> I wait for yours feedback, and I hope this could be usefull
> >
> > Hi Pablo,
> >
> > 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.
> >
> > Andrew
> >
> > --
> > 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.
> >
>
> --
> 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.
>

-- 
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.

Re: Smart extends

[J . Pablo Martín Cobos]

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 

>
> On Fri, Oct 15, 2010 at 6:09 AM, Andrew Godwin 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.
>

-- 
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.

Re: Smart extends

[J . Pablo Martín Cobos]

Hi Harro,

This templatetag is different that the one you implemented. I don't feel
dirty  :-P

Regards,

--
Pablo Martín


2010/10/15 Harro 

> I wrote an extends tag once that changed the extending template based
> on a get variable..
> The idea was that we could then simply get a part of the website in a
> lightbox popup without all the "outer content".
> I removed it afterwards and we did it properly.. it felt dirty.
>
> On Oct 15, 3:29 pm, Luke Plant  wrote:
> > On Fri, 2010-10-15 at 14:41 +0200, J. Pablo Martín Cobos wrote:
> >
> > > To perform something like this, we should copy all the change_list
> > > template (i.e. 100 lines of code), in order to add this two changes.
> >
> > Have you seenhttp://code.djangoproject.com/wiki/ExtendingTemplates?
> >
> > Thanks,
> >
> > Luke
> >
> > --
> > "I asked mom if I was a gifted child. She said they certainly
> > wouldn't have paid for me." (Calvin and Hobbes)
> >
> > Luke Plant ||http://lukeplant.me.uk/
>
> --
> 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.
>
>

-- 
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.

Re: Smart extends

[J . Pablo Martín Cobos]

Hi luke,

Thanks in advance, but of course I have seen this wiki, but I had wrotten in
my first e-mail I needed and wanted more funcionallity. I think we have to
change a little the inheritance of templates, this wiki is from 2008, so I
think it's possible to add new funcionality.

It would be very good for me that the new funcionality that I have
implemented would be added to django project. If not I hope this could be
usefull for somebody

Regards,

--
Pablo Martín


2010/10/15 Luke Plant 

> On Fri, 2010-10-15 at 14:41 +0200, J. Pablo Martín Cobos wrote:
>
> > To perform something like this, we should copy all the change_list
> > template (i.e. 100 lines of code), in order to add this two changes.
>
> Have you seen http://code.djangoproject.com/wiki/ExtendingTemplates ?
>
> Thanks,
>
> Luke
>
> --
> "I asked mom if I was a gifted child. She said they certainly
> wouldn't have paid for me." (Calvin and Hobbes)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> 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.
>
>

-- 
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.

Re: Smart extends

[J . Pablo Martín Cobos]

Hi Andrew,

I think that in my first e-mail I didn't explain well the problem. Really it
was a difficult for me explain it even in spanish with my workmate, but at
the end they all agree with me.

Really the problem comes when we reuse a application: from other people,
from Django (i.e. django.contrib.admin), or even my own that we reuse in
some projects. Usually you want to change slight things and usually you want
only to change the visualization mode, you want to change the templates. You
need to adapt the application to your project.

Many times I had to overwrite some templates, of the some application that I
had reuse, and I had to overwrite all the template, and this is very dirty
(for me). It's possible to do in ModelAdmin as you say, but it is more
confuse way to do. Especially when the ModelAdmin of the application is not
yours and it is not set change_list_template. It's possible, but I think
that it's a more difficult solution. But really it was only a example.

I tell you another example. I have use many times, in various projects, i.e.
django-messages [1] i I wanted to overwrite the base template [2] and add
one class in the block "bodyclass" I had to copy all the template. In this
case, is not so a problem  because they are only 13 lines, but you can
imagine that it can have 100 lines, or more like change_list template.

Regards and thanks


--
REF's

1. http://code.google.com/p/django-messages/
2.
http://code.google.com/p/django-messages/source/browse/trunk/django_messages/templates/django_messages/base.html

--

Pablo Martín

El 15 de octubre de 2010 14:41, J. Pablo Martín Cobos
<goi...@gmail.com>escribió:

> Hi,
>
> I'm a Django developer since more or less 3 years. Some time ago I had the
> need for the extends templatetag to have more funcionality.
>
> The funcionality I mean is that a template can extends from "itself". I'm
> going to try to explain it better, so I will put Django admin as an example,
> although I needed it in others places. In many projects I wanted to
> customize the admin site, I wanted to tiny modify the change_list template
> or the change_form template, etc. I.E. like the following:
>
> file:templates/admin/change_list.html
>
> {% extends "admin/change_list.html" %}
>
> {% block extrastyle %}
> {{ block.super }}
> 
> {% endblock %}
>
>
> {% block breadcrumbs %}
> 
> 
> {% trans "My Project" %}
> 
> 
> 
> {{ app_label|capfirst }}
> 
> 
> {{ cl.opts.verbose_name_plural|capfirst }}
> 
> {% endblock %}
>
>
> To perform something like this, we should copy all the change_list template
> (i.e. 100 lines of code), in order to add this two changes. For this subject
> I created a google-code project [1], wich is working in a little project of
> Universidad de Granada [2] succesfully.
>
> I wait for yours feedback, and I hope this could be usefull
>
> Regards,
>
> --
>
> REF's
>
> 1. http://code.google.com/p/django-smart-extends/
> 2. http://spinoff.ugr.es/
>
> --
>
> Pablo Martín
>

-- 
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.

Re: Smart extends

[Dougal Matthews]

I can see one main use case. Front end developers and designers would be
able to extend templates without worrying about python code changes or doing
a full copy and paste of the original template (if they can find it.)

Dougal
 On 15 Oct 2010 14:10, "Andrew Godwin"  wrote:
> On 15/10/10 13:41, J. Pablo Martín Cobos wrote:
>> Hi,
>>
>> I'm a Django developer since more or less 3 years. Some time ago I had
>> the need for the extends templatetag to have more funcionality.
>>
>> The funcionality I mean is that a template can extends from "itself".
>> I'm going to try to explain it better, so I will put Django admin as
>> an example, although I needed it in others places. In many projects I
>> wanted to customize the admin site, I wanted to tiny modify the
>> change_list template or the change_form template, etc. I.E. like the
>> following:
>>
>> file:templates/admin/change_list.html
>>
>> {% extends "admin/change_list.html" %}
>>
>> {% block extrastyle %}
>> {{ block.super }}
>> 
>> {% endblock %}
>>
>>
>> {% block breadcrumbs %}
>> 
>> 
>> {% trans "My Project" %}
>> 
>> 
>> 
>> {{ app_label|capfirst }}
>> 
>> 
>> {{ cl.opts.verbose_name_plural|capfirst }}
>> 
>> {% endblock %}
>>
>>
>> To perform something like this, we should copy all the change_list
>> template (i.e. 100 lines of code), in order to add this two changes.
>> For this subject I created a google-code project [1], wich is working
>> in a little project of Universidad de Granada [2] succesfully.
>>
>> I wait for yours feedback, and I hope this could be usefull
>
> Hi Pablo,
>
> 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.
>
> Andrew
>
> --
> 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.
>

-- 
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.

Re: Smart extends

[Andy McCurdy]

On Fri, Oct 15, 2010 at 6:09 AM, Andrew Godwin  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.

Re: Smart extends

[Harro]

I wrote an extends tag once that changed the extending template based
on a get variable..
The idea was that we could then simply get a part of the website in a
lightbox popup without all the "outer content".
I removed it afterwards and we did it properly.. it felt dirty.

On Oct 15, 3:29 pm, Luke Plant  wrote:
> On Fri, 2010-10-15 at 14:41 +0200, J. Pablo Martín Cobos wrote:
>
> > To perform something like this, we should copy all the change_list
> > template (i.e. 100 lines of code), in order to add this two changes.
>
> Have you seenhttp://code.djangoproject.com/wiki/ExtendingTemplates?
>
> Thanks,
>
> Luke
>
> --
> "I asked mom if I was a gifted child. She said they certainly
> wouldn't have paid for me." (Calvin and Hobbes)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
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.

Re: Smart extends

[Andrew Godwin]

On 15/10/10 13:41, J. Pablo Martín Cobos wrote:

Hi,

I'm a Django developer since more or less 3 years. Some time ago I had 
the need for the extends templatetag to have more funcionality.


The funcionality I mean is that a template can extends from "itself". 
I'm going to try to explain it better, so I will put Django admin as 
an example, although I needed it in others places. In many projects I 
wanted to customize the admin site, I wanted to tiny modify the 
change_list template or the change_form template, etc. I.E. like the 
following:


file:templates/admin/change_list.html

{% extends "admin/change_list.html" %}

{% block extrastyle %}
{{ block.super }}


{% endblock %}


{% block breadcrumbs %}


{% trans "My Project" %}



{{ app_label|capfirst }}


{{ cl.opts.verbose_name_plural|capfirst }}

{% endblock %}


To perform something like this, we should copy all the change_list 
template (i.e. 100 lines of code), in order to add this two changes. 
For this subject I created a google-code project [1], wich is working 
in a little project of Universidad de Granada [2] succesfully.


I wait for yours feedback, and I hope this could be usefull


Hi Pablo,

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.


Andrew

--
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.

Smart extends

[J . Pablo Martín Cobos]

Hi,

I'm a Django developer since more or less 3 years. Some time ago I had the
need for the extends templatetag to have more funcionality.

The funcionality I mean is that a template can extends from "itself". I'm
going to try to explain it better, so I will put Django admin as an example,
although I needed it in others places. In many projects I wanted to
customize the admin site, I wanted to tiny modify the change_list template
or the change_form template, etc. I.E. like the following:

file:templates/admin/change_list.html

{% extends "admin/change_list.html" %}

{% block extrastyle %}
{{ block.super }}

{% endblock %}


{% block breadcrumbs %}


{% trans "My Project" %}



{{ app_label|capfirst }}


{{ cl.opts.verbose_name_plural|capfirst }}

{% endblock %}


To perform something like this, we should copy all the change_list template
(i.e. 100 lines of code), in order to add this two changes. For this subject
I created a google-code project [1], wich is working in a little project of
Universidad de Granada [2] succesfully.

I wait for yours feedback, and I hope this could be usefull

Regards,

--

REF's

1. http://code.google.com/p/django-smart-extends/
2. http://spinoff.ugr.es/

--

Pablo Martín

-- 
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.