Re: #6375 -- Class Based Views: Opinions on commit plan

[Ian Lewis]

On Sat, Oct 16, 2010 at 1:31 PM, Yo-Yo Ma  wrote:

> Łukasz Rekucki,
>
> Thanks for the reply. I wasn't being cynical when I said:
>
> > If the API for this feature was not so intrinsically
> > obscure, it might be a more obvious choice to include it right away,
>
> What I meant was the design and implementation creates an unusable API
> by default. This is a sign that it's not quite ready. I don't suggest
> putting it off for another 2 years, but now that things are really
> starting to roll with Django, and more developers are getting added,
> it's worst time to start shoveling things in that a lot of people
> don't like, crippling production and evolution that could otherwise
> come very quickly now.
>
> > come help out!
>
> What do you call this. I don't see how any software developer could
> consider constructive criticism as anything other than helping out.
> Just about 90% of software development is in the mind (at least for
> me), and the other 10% is spent typing as fast as I can.
>

Are you arguing that the API is bad or are you arguing that features where
the API could change shouldn't land in trunk? If you are arguing for the
former then I think you'll need to be a lot more concrete about what you
don't like and how to fix it to really get traction at this point. If it's
the later then I can see the point, I know I have tracked trunk in the past
when developing projects (I know it's not a great idea), but I think the
merits of getting things tested properly outweighs the demerits in this case
so it's worth trying out. I wouldn't think the API will change much anyway.

-- 
Ian

http://www.ianlewis.org/

-- 
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 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: #6375 -- Class Based Views: Opinions on commit plan

[Łukasz Rekucki]

On 15 October 2010 21:40, Yo-Yo Ma  wrote:
> My strong suggestion (again prima facie to this discussion) is:
>
> Do not include something as controversial into the trunk, especially
> with the justification of, "There are quite a few sets of class-based
> views out there".

That section probably needs extending, but imho it didn't get much
love, because we pretty much all agree we need this feature for
reusable apps to make sense. The only question is how to do it and
this was discussed many times in the passed, discussed on
DjangoCon[1][2] and recently on this mailing list for over a week with
over 100 posts. So, no - that's not the only justification.

> If the API for this feature was not so intrinsically
> obscure, it might be a more obvious choice to include it right away,

This isn't very constructive. If you want to show us a better API,
just fork Rusell's code[3] and go ahead.

> but considering the "don't break the API" locked in nature of Django's
> trunk, it might be worth rehashing this argument after 1.3. Almost
> making it into the trunk will have surely opened a lot of eyes and
> will undoubtedly bring about new Git Hub forks with possibly better
> implementations and alternative APIs for class-based views. Something
> much better will come and it'll be too late.

So we should because there might be a better solution in next 6 months
? I don't think that is how "perfectionists with deadlines" work. This
is something that has been considered for over 2 years now. Perfection
is good, but the deadline is almost here, IMHO.

So if you really are concerned with state of CBV, come help out! Just
shouting "your API sucks" doesn't help anyone.

[1]: http://blip.tv/file/4109272
[2]: http://blip.tv/file/4108781
[3]: http://bitbucket.org/freakboy3742/django

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

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: parse xml

[Horst Gutmann]

I so hope this response was the result of some translation gone wrong.
If not, you shouldn't really expect anyone to answer your (highly off-
topic) question with that attitude...

On Oct 15, 7:56 pm, kostia  wrote:
> Give me the answer and do what you want.
>
> On Oct 15, 8:45 pm, Alex Gaynor  wrote:
>
>
>
>
>
>
>
> > On Fri, Oct 15, 2010 at 1:38 PM, kostia  wrote:
> > > I have xml file:
> > > 
> > > 
> > >        5
> > > 
>
> > > I want to get the value of n (= 5) inside my python program, I'm
> > > doing this:
>
> > > import xml.dom.minidom
> > > from xml.dom.minidom import Node
> > > doc = xml.dom.minidom.parseString("boolean_width.xml")
> > > n = doc.getElementsByTagName("root")[0].firstChild.nodeValue.strip()
> > > print n
>
> > > and it is failed. How to get the value? Please, help.
>
> > > --
> > > 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 
> > > athttp://groups.google.com/group/django-developers?hl=en.
>
> > Hi,
>
> > The django-developers mailing list is for discussion about the
> > development of Django itself, not discussion about development with
> > Django.  For that you'd want django-users (or in this case probably
> > python-list, aka comp.lang.python).
>
> > Alex
>
> > --
> > "I disapprove of what you say, but I will defend to the death your
> > right to say it." -- Voltaire
> > "The people's good is the highest law." -- Cicero
> > "Code can always be simpler than you think, but never as simple as you
> > want" -- Me

-- 
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: #6375 -- Class Based Views: Opinions on commit plan

[Yo-Yo Ma]

My strong suggestion (again prima facie to this discussion) is:

Do not include something as controversial into the trunk, especially
with the justification of, "There are quite a few sets of class-based
views out there". If the API for this feature was not so intrinsically
obscure, it might be a more obvious choice to include it right away,
but considering the "don't break the API" locked in nature of Django's
trunk, it might be worth rehashing this argument after 1.3. Almost
making it into the trunk will have surely opened a lot of eyes and
will undoubtedly bring about new Git Hub forks with possibly better
implementations and alternative APIs for class-based views. Something
much better will come and it'll be too late.

,
On Oct 15, 12:11 am, Russell Keith-Magee 
wrote:
> On Fri, Oct 15, 2010 at 1:59 PM, Yo-Yo Ma  wrote:
> > I realize this is a bit late and not even the "right" discussion, bit
> > I just stumbled across this and the wiki, and I feel a bit sick to my
> > stomach.
>
> > 1) self.request?
>
> > Whatever gains come from this will be offset by loss in design. A
> > method is called by a request. That is simple common sense. A method
> > doesn't access a request. I'm sorry, if I'm missing something here,
> > but this seems as backward as an intentional sabotage to Django would
> > be.
>
> > 2) "getting in the way if you do want to share a lot of code between
> > GET and POST methods"
>
> > For those of us not reinventing the blog, or creating content sites,
> > this is an automatic disadvantage.
>
> > 3) .as_view()?
>
> > Nothing needs to be said about the confusing mess that is the class
> > based views API.
>
> In fact, a great deal *has* been said. The most recent mailing list
> thread about this exact topic ran to *over 100 messages*. That's the
> second mailing list thread in recent memory that ran to comparable
> length, and the topic has been discussed many times over the years.
>
> as_view() exists for a very good reason. The same goes for
> self.request, and the dispatch mechanism.
>
> It seems to me that before you weigh into a discussion that you've
> "just stumbled into", and you're concerned by what you see, you might
> want to avail yourself of the opportunity reading the history that has
> led us to the design that we have on the table. We're not stupid, and
> the designs that exist, exist for a reason.
>
> We're happy to entertain design suggestions, but only if they're
> enlightened by the extensive discussions that have proceeded the
> implementation that we have. You're free to say "as_view() sucks", but
> unless you are proposing an *specific* alternative that isn't fraught
> with the problems that led us to that solution in the first place,
> you're not going to get much traction.
>
> Yours,
> Russ Magee %-)

-- 
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
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: parse xml

[kostia]

Give me the answer and do what you want.

On Oct 15, 8:45 pm, Alex Gaynor  wrote:
> On Fri, Oct 15, 2010 at 1:38 PM, kostia  wrote:
> > I have xml file:
> > 
> > 
> >        5
> > 
>
> > I want to get the value of n (= 5) inside my python program, I'm
> > doing this:
>
> > import xml.dom.minidom
> > from xml.dom.minidom import Node
> > doc = xml.dom.minidom.parseString("boolean_width.xml")
> > n = doc.getElementsByTagName("root")[0].firstChild.nodeValue.strip()
> > print n
>
> > and it is failed. How to get the value? Please, help.
>
> > --
> > 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 
> > athttp://groups.google.com/group/django-developers?hl=en.
>
> Hi,
>
> The django-developers mailing list is for discussion about the
> development of Django itself, not discussion about development with
> Django.  For that you'd want django-users (or in this case probably
> python-list, aka comp.lang.python).
>
> Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your
> right to say it." -- Voltaire
> "The people's good is the highest law." -- Cicero
> "Code can always be simpler than you think, but never as simple as you
> want" -- Me

-- 
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: parse xml

[Alex Gaynor]

On Fri, Oct 15, 2010 at 1:38 PM, kostia  wrote:
> I have xml file:
> 
> 
>        5
> 
>
> I want to get the value of n (= 5) inside my python program, I'm
> doing this:
>
> import xml.dom.minidom
> from xml.dom.minidom import Node
> doc = xml.dom.minidom.parseString("boolean_width.xml")
> n = doc.getElementsByTagName("root")[0].firstChild.nodeValue.strip()
> print n
>
> and it is failed. How to get the value? Please, help.
>
> --
> 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.
>
>

Hi,

The django-developers mailing list is for discussion about the
development of Django itself, not discussion about development with
Django.  For that you'd want django-users (or in this case probably
python-list, aka comp.lang.python).

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

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

parse xml

[kostia]

I have xml file:


5


I want to get the value of n (= 5) inside my python program, I'm
doing this:

import xml.dom.minidom
from xml.dom.minidom import Node
doc = xml.dom.minidom.parseString("boolean_width.xml")
n = doc.getElementsByTagName("root")[0].firstChild.nodeValue.strip()
print n

and it is failed. How to get the value? Please, help.

-- 
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: #6375 -- Class Based Views: Opinions on commit plan

[Russell Keith-Magee]

On Fri, Oct 15, 2010 at 1:09 AM, Justin Lilly  wrote:
> Because you asked, I think this sounds like a great idea.
>
> When you have decided you like the API for create/update
> views, please send another email to the list, so that we
> know we've hit a stable API to write documentation
> against.

I've finished my review of the create/update and date views. I've also
tweaked aspects of the base, detail and list views following feedback
and suggestions from IRC.

I've also added the placeholder skeleton of some documentation:
 * a reference guide
 * a topic guide, and
 * a migration guide

So - review and document away :-)

Yours,
Russ Magee %-)

-- 
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: Template preprocessing (to improve template rendering speed, en page filesize)

[Brendan Smith]

Jonathan,   I don't know if this is the proper place to post this, unless
you are looking to have it added to core.  I have a feeling core
contributors are going to chime in and say this more than likely belongs the
in django-users mailing list.  When you post it there though, I for one
think this sounds like a great little project and will definitely e
interested in taking a look at this, if your company is willing to
open-source it.



On Fri, Oct 15, 2010 at 10:35 AM, Jonathan S wrote:

> Hi all,
>
> At my current job, I spent a week of programming on a preprocessor for
> Django templates.
> In short, what it does is compiling the templates in a more compact
> version, dropping all useless information and preprocessing
> templatetags where possible. The Apache benchmark tools showed a page
> load improvement up to twice as fast in Django 1.2, and 4 times as
> fast in the older Django version and HTML pages are now only half as
> big in filesize now.
>
> It is completely transparent, there are no changes needed to the
> templates, and should only be installed as a template loader (wrapping
> around the original loaders).
>
> What is does, in the Django language is:
> * preprocess {% trans %} and {% blocktrans %} when they don't take
> variables parameters. (the template loader will have a 'cache' for
> each language)
> * preprocess inheritance. Combining parent and child templates by
> replacing the blocks, and filling in {{block.super}}. {% block %} tags
> can be removed because all inheritance has been determined. (Note,
> this doesn't work with {% extends variable_name %}, but I think it's a
> bad idea to have variable inheritance. (but can be disabled if you
> would need it.)
> * preprocess {% include "path" %}, if path is not a variable.
> * grouping {% load statements %}
> * resolve all {% url %} when they don't take variable parameters.
> * preprocess {% now "Y" %}  (we will restart our server at least once,
> after a year transition. :p )
> * We have a few tags, like {% google_analytics %}, which constantly
> output the same code, this is implemented as a custom preprocessor
> extension for ourself.
>
> Now, if the template is HTML, we do a little more optimizations:
> * Remove all whitespace between block-level HTML tags
> * Removing empty class attributes, like class="", (which may appear as
> a result of class="{% block name %}{% endblock %}", where the child
> template din't implement the block.)
> * Merge all 

Template preprocessing (to improve template rendering speed, en page filesize)

[Jonathan S]

Hi all,

At my current job, I spent a week of programming on a preprocessor for
Django templates.
In short, what it does is compiling the templates in a more compact
version, dropping all useless information and preprocessing
templatetags where possible. The Apache benchmark tools showed a page
load improvement up to twice as fast in Django 1.2, and 4 times as
fast in the older Django version and HTML pages are now only half as
big in filesize now.

It is completely transparent, there are no changes needed to the
templates, and should only be installed as a template loader (wrapping
around the original loaders).

What is does, in the Django language is:
* preprocess {% trans %} and {% blocktrans %} when they don't take
variables parameters. (the template loader will have a 'cache' for
each language)
* preprocess inheritance. Combining parent and child templates by
replacing the blocks, and filling in {{block.super}}. {% block %} tags
can be removed because all inheritance has been determined. (Note,
this doesn't work with {% extends variable_name %}, but I think it's a
bad idea to have variable inheritance. (but can be disabled if you
would need it.)
* preprocess {% include "path" %}, if path is not a variable.
* grouping {% load statements %}
* resolve all {% url %} when they don't take variable parameters.
* preprocess {% now "Y" %}  (we will restart our server at least once,
after a year transition. :p )
* We have a few tags, like {% google_analytics %}, which constantly
output the same code, this is implemented as a custom preprocessor
extension for ourself.

Now, if the template is HTML, we do a little more optimizations:
* Remove all whitespace between block-level HTML tags
* Removing empty class attributes, like class="", (which may appear as
a result of class="{% block name %}{% endblock %}", where the child
template din't implement the block.)
* Merge all 

Re: #6375 -- Class Based Views: Opinions on commit plan

[Andrew Godwin]

On 15/10/10 14:52, Ian Lewis wrote:
On Fri, Oct 15, 2010 at 2:06 PM, Russell Keith-Magee 
> wrote:



However, this isn't a decision we need to make right now. If we land
what we have, we can fiddle with it until the RC comes out; if we are
getting to that point and we're making API changes, we can look at our
options for providing adequate warnings.


I'm with Russ here. I'd be wary of introducing exceptions to the 
current backwards-compat policy. It's relatively simple, many people 
are familiar with it, and I don't think it should change in surprising 
ways. The 'from __future__' idea is compelling and I like it but I 
would avoid introducing half baked features in a Django release. I 
expect most people like frameworks to "work".


Me too; if it's half-baked, people are still going to get annoyed when 
we start changing it, and otherwise aren't going to use/test it 
properly. It's not like we're getting rid of the old function-based 
generic views, either.


It's well known that people don't really test stuff properly till it 
lands in trunk, and I think it's a mature enough implementation that 
we're better off landing it and getting feedback than putting it in a 
special corner and bikeshedding a bit more. I'd rather get feedback from 
the userbase at large, which I think is where we'll really learn what 
needs changing, if anything.


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.

Django/Python developers- Multiple Positions in Atlanta

[Jack]

Good Morning!

I am looking for Django/Python developers to join the team of one our
clients working on one of the largest Django apps EVER - scaled to
serve web,mobile, and more for 100+ prominent newspaper, TV, and radio
sites! There are 3-5 job openings and they are looking for someone who
can hit the ground running! Please send me an e-mail at
jmabb...@apexsystemsinc.co or call at (770) 481-0044 and I would love
to tell you more details!

Please reply if you or someone you know if looking for a job as a
expert Python or Django Developer.

only US Citizens or Greencard holders need apply

Thanks!

Jack

-- 
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: #6375 -- Class Based Views: Opinions on commit plan

[Ian Lewis]

On Fri, Oct 15, 2010 at 2:06 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> > There is this crazy idea im my mind to mark CBVs API as
> > "Beta" in 1.3 and put a big warning in the docs that it can change in
> > backwards-incompatible was in 1.4. A precedence to this would be
> > `databrowse`[1], but we could actually finish it this time ;).
>
> That thought has occurred to me in the past. My concern is how we
> manage such an idea as a project. Backwards compatibility is a big
> deal, and one of Django's big selling points IMHO.
>
> So - the question becomes how can we introduce a new feature, but give
> people fair warning that they're using a feature that is subject to
> change? Python's 'from __future__' is a really good approach to this,
> IMHO -- i.e., an explicit opt-in to new features. There might be some
> room to explore this sort of idea for Django.
>
> However, this isn't a decision we need to make right now. If we land
> what we have, we can fiddle with it until the RC comes out; if we are
> getting to that point and we're making API changes, we can look at our
> options for providing adequate warnings.


I'm with Russ here. I'd be wary of introducing exceptions to the current
backwards-compat policy. It's relatively simple, many people are familiar
with it, and I don't think it should change in surprising ways. The 'from
__future__' idea is compelling and I like it but I would avoid introducing
half baked features in a Django release. I expect most people like
frameworks to "work".

-- 
Ian

http://www.ianlewis.org/

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

Re: #6375 -- Class Based Views: Opinions on commit plan

[Russell Keith-Magee]

On Fri, Oct 15, 2010 at 8:30 PM, David De La Harpe Golden
 wrote:
> On 15/10/10 07:11, Russell Keith-Magee wrote:
>
>> We're happy to entertain design suggestions, but only if they're
>> enlightened by the extensive discussions that have proceeded the
>> implementation that we have. You're free to say "as_view() sucks", but
>> unless you are proposing an *specific* alternative that isn't fraught
>> with the problems that led us to that solution in the first place,
>> you're not going to get much traction.
>>
>
> I find the use of an .as_view() direct classmethod vaguely peculiar
> given classmethods have been avoided elsewhere in django in favor of the
> flexible "Manager" pattern?
>
> Why not have views class property on the class by analogy with the
> "objects" property, that the resolver calls a "get" method on with the
> params to get a view instance?

Why not? Because of decoration. If the URL resolver needs to
manipulate the thing that is defined in a URL pattern, that means you
can't use decorators in the URL pattern. See the wiki for more details
[1].

To try and head this off at the pass: when I said any feedback is
welcome, I was really referring to the organization of the class-based
views themselves, not the dispatch mechanism. There's been a *lot* of
thought put into the dispatch mechanism -- read the archives if you
don't believe me -- and we've come to the conclusion that as_view() is
the best of a less-than-ideal set of solutions.

If you *really* think you've discovered the perfect solution that
nobody else has proposed:

 1) No, really, you haven't. Check the wiki archives, and I'll give
good odds that *someone* has proposed your idea before, and the
problems that exist with the idea have been explored.

 2) If your specific idea hasn't been suggested, it can probably be
ruled out for one of the clearly documented reasons in the wiki, so
you'd better be *really* certain that it addresses the issues that are
described in the wiki.

 3) You'd better come armed with a demonstration implementation that,
at the very least, meets all the use cases described by Luke Plant's
experimentation suite [2].

I'm sorry if this seems rude or curt, but the last thing we need at
this point is another round of attempted bikeshedding on dispatch
mechanisms. This isn't a trivial problem. A lot of thought has gone
into the solution that is on the table. If you're going to enter the
discussion at this late stage, the very least you can do is give the
rest of the community the courtesy of coming up to speed with the
debate so we don't have to rehash old ground yet again.

[1] http://code.djangoproject.com/wiki/ClassBasedViews
[2] http://bitbucket.org/spookylukey/django-class-views-experiments/src/tip/

Yours,
Russ Magee %-)

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

Re: #6375 -- Class Based Views: Opinions on commit plan

[David De La Harpe Golden]

On 15/10/10 07:11, Russell Keith-Magee wrote:

> We're happy to entertain design suggestions, but only if they're
> enlightened by the extensive discussions that have proceeded the
> implementation that we have. You're free to say "as_view() sucks", but
> unless you are proposing an *specific* alternative that isn't fraught
> with the problems that led us to that solution in the first place,
> you're not going to get much traction.
> 

I find the use of an .as_view() direct classmethod vaguely peculiar
given classmethods have been avoided elsewhere in django in favor of the
flexible "Manager" pattern?

Why not have views class property on the class by analogy with the
"objects" property, that the resolver calls a "get" method on with the
params to get a view instance?

class BlahViewDirector(Director):  # director:view::manager:model
   ...

class Blah(View):
   views = BlahDirector()  # or left out for a "default director"
   ...


url(r'blah/(?P\d+)/$'), views.Blah, name="blah")
url(r'blah/(?P\d+)/glonk/$'), views.Blah, glonk=True)

=>
Blah.views.get(key=key) and
Blah.views.get(key=key, glonk=True) to get a Blah instance
that's perhaps itself a callable expecting a request, or has
GET/POST/PUT etc. methods.

Wouldn't that be rather more in keeping with the structure of the rest
of the framework?  A Director could be simple or sophisticated
(e.g. caching and reusing instances thread-safely), much like a Manager.








-- 
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: #6375 -- Class Based Views: Opinions on commit plan

[Sebastian Pawlus]

Maybe not important but makes bit harder to find in it trac :)
Russ there is a typo in subject, ticket id is #6735, not 6375.


On Fri, Oct 15, 2010 at 8:11 AM, Russell Keith-Magee
 wrote:
> On Fri, Oct 15, 2010 at 1:59 PM, Yo-Yo Ma  wrote:
>> I realize this is a bit late and not even the "right" discussion, bit
>> I just stumbled across this and the wiki, and I feel a bit sick to my
>> stomach.
>>
>> 1) self.request?
>>
>> Whatever gains come from this will be offset by loss in design. A
>> method is called by a request. That is simple common sense. A method
>> doesn't access a request. I'm sorry, if I'm missing something here,
>> but this seems as backward as an intentional sabotage to Django would
>> be.
>>
>> 2) "getting in the way if you do want to share a lot of code between
>> GET and POST methods"
>>
>> For those of us not reinventing the blog, or creating content sites,
>> this is an automatic disadvantage.
>>
>> 3) .as_view()?
>>
>> Nothing needs to be said about the confusing mess that is the class
>> based views API.
>
> In fact, a great deal *has* been said. The most recent mailing list
> thread about this exact topic ran to *over 100 messages*. That's the
> second mailing list thread in recent memory that ran to comparable
> length, and the topic has been discussed many times over the years.
>
> as_view() exists for a very good reason. The same goes for
> self.request, and the dispatch mechanism.
>
> It seems to me that before you weigh into a discussion that you've
> "just stumbled into", and you're concerned by what you see, you might
> want to avail yourself of the opportunity reading the history that has
> led us to the design that we have on the table. We're not stupid, and
> the designs that exist, exist for a reason.
>
> We're happy to entertain design suggestions, but only if they're
> enlightened by the extensive discussions that have proceeded the
> implementation that we have. You're free to say "as_view() sucks", but
> unless you are proposing an *specific* alternative that isn't fraught
> with the problems that led us to that solution in the first place,
> you're not going to get much traction.
>
> Yours,
> Russ Magee %-)
>
> --
> 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.