Re: Gentle Proposal: add 'render' shortcut in 1.3
On 10/25/2010 04:33 PM, Russell Keith-Magee wrote: * The problem with messages is a big one -- probably even a show-stopper if we can't find a way to reconcile the general use case that it represents (i.e., we don't just need a fix for contrib.messages -- we need to explain how/why the problem exists, and provide a consistent approach for analogous problems) I apologize in advance if I missed some important bits of the conversation — I'm on vacation right now :-). Why can't we teach messages middleware to just explicitly bake a response and call it a proper solution? By adding `force_bake` to the HttpResponse class itself we effectively declare that *any* HttpResponse can be lazy and middleware that expects some side-effects from a response has to bake it. Sure it must be documented that middleware forcing response baking should work after the ones that don't. -- 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: Ticket #7817: Extending "with" and "include" tags.
On Oct 27, 5:35 am, Łukasz Rekucki wrote:
> I would like to bring this up again, because this is something that
> would really improve readability of my templates. I'm mainly
> interested in ticket #7817 (the include tag changes), but extending
> "with" tag (ticket 9456) would keep things consistent.
Here's a link to the ticket for the lazier ones among us:
http://code.djangoproject.com/ticket/7817
The main decision which needs to be made is one of syntax.
The current proposal uses:
{% include "name_snippet.html" with name="Joe" greeting="Hello" %}
but this introduces an inconsistency with the {% with %} tag.
Consistency would be nice, but I think this starts to look a bit
confusing, static tokens outnumbering actual functional ones:
{% include "name_snippet.html" with name as "Joe" and greeting as
"Hello" %}
My proposal is that the current {% with name as "Joe" %} format
becomes the legacy format, and that the new format becomes (also
allowing for multiple arguments):
{% with name="Joe" greeting="Hello" %}
Other tags which currently use the "as" token are: cycle, regroup and
url. These all introduce a new variable into the current context,
which does differ slightly from how {% with %} alters a variable in a
contained scope. So my secondary (perhaps somewhat feeble) argument is
that this actually helps to keep the "as" token's behaviour more
consistent. :)
Thoughts?
--
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: Ticket #7817: Extending "with" and "include" tags.
> Other tags which currently use the "as" token are: cycle, regroup and
> url. These all introduce a new variable into the current context,
> which does differ slightly from how {% with %} alters a variable in a
> contained scope. So my secondary (perhaps somewhat feeble) argument is
> that this actually helps to keep the "as" token's behaviour more
> consistent. :)
Don't forget {% blocktrans %}. Using the foo=bar-syntax here may be
slightly more difficult due to counted arguments.
{% blocktrans count foo as var1 and bar as var2 %}
Could become:
{% blocktrans count var1=foo var2=bar %}
David
--
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: prepopulated_fields javascript error since r14123
On 27/10/10 07:01, Simon Meers wrote: Has anyone else found that using prepopulated_fields in admin.ModelAdmin since r14123 produces a javascript error: "d.join is not a function"? I didn't get any errors when I tested the patch before commit - are you having them on the 1.2.X backport, or the main trunk version? 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: contrib.staticfiles app concerns
On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald wrote: > OK, I just went through django-mediagenerator to check if there's > anything else needed by staticfiles and I noticed that we need to have > a standard for URLs in CSS files (e.g., url(image.png)). > > Since we don't know the STATICFILES_URL in our CSS code we have to use > relative paths when referencing images. When CSS files get combined > the resulting file is often in a different folder than its source > files. This will break relative paths. Now we have these solutions: > 1. keep URLs untouched when combining > 2. rewrite URLs relative to source files > 3. rewrite URLs relative to the combined file's path > 4. rewrite URLs relative to STATICFILES_URL > > URL rewriting would convert relative paths to absolute URLs beginning > with STATICFILES_URL. > > (1) is the easiest solution and it might be used by very simple asset > managers. This approach is also used by quite a few CSS and JS > frameworks (e.g. jQuery UI). Disadvantage: It only works if the > combined CSS file is in the same location as its source files. > > (2) is very intuitive because it behaves exactly like with uncombined > files. Disadvantage: URL rewriting is inconsistent if you also support > CSS compilers like Sass because the URLs used in imported files would > be relative to the master file. This means imported files have to make > assumptions about the master file's location which is very confusing > and bad for reusability. > > (3) is too confusing and makes too many assumptions about the combined > file's location which is confusing and bad for reusability. > > (4) is the most consistent solution. No matter whether you use a CSS > compiler or normal CSS files or something else, URLs always behave the > same. Disadvantage: At first you might expect different behavior, so > it's quite not as intuitive as (2), but it's very easy to understand > once you know what it does. Also, it doesn't have any of the > disadvantages of (2). > > IMHO, (4) is the best solution because it's consistent. (2) is the > second best solution. It should be easy to adapt the code in > django-mediagenerator and make a little patch for staticfiles, so it > behaves like (4). What do you think? > > In any case, staticfiles would need to rewrite URLs in its view, too. > Otherwise we can't provide a consistent solution across all asset > managers. Since this is pretty important and it would be great to have in the alpha release, what do you need to be able to make a good decision, here? Bye, Waldemar -- 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: It is real to add ticket #8054 to 1.3 milestone?
Hi Alex and Yuri, To make it clear: is this only a syntax change and all other benefits can be achieved with current implementation? The benefits from the wiki: 1. ability to customize and localize 3rd-party application without fork it - it is as easy with current ModelAdmin. ModelAdmin looks up it's own methods so 'get_bar_column' in wiki can be put into AccountAdmin. 2. ability to apply custom template filters on field value or model method returned value without any magic - it is also possible: template filters are just functions and @register.filter decorator doesn't harm them. 3. ability to specify witch field will be used in order for column based on model method - this is also totally possible with current implementation 4. beautifully API to admin change list customization - as I can see it is the only benefit here Am I correct and the goal is only to change list_display syntax? On 27 окт, 10:58, "burc...@gmail.com" wrote: > Hi Alex, > > Patch is looking good, except few small things. > Wiki docs are also very good, but they are quite incomplete. > Replied to the ticket. > > > > > > On Tue, Oct 26, 2010 at 11:23 PM, Alex Kamedov wrote: > > Can anybody rewiew the patch? > > > On Wed, Oct 13, 2010 at 6:35 PM, Alex Kamedov wrote: > > >> Hi All, > >> I uploaded patch with tests and little improvements > > >>http://code.djangoproject.com/attachment/ticket/8054/8054-list-column... > >> I think it ready for review. > >> I really sorry, but I couldn't write good documentation because English > >> isn't my own language. The maximum of my possibility in writing docs is > >> here http://code.djangoproject.com/wiki/ListColumns For more examples see > >> folder admin_listcolumn in regression tests provided by last my patch. > >> Cheers, > >> Alex Kamedov > >> On Wed, Oct 13, 2010 at 2:12 AM, Gabriel Hurley wrote: > > >>> Hi alekam, > > >>> This is certainly the kind of ticket that we want to deal with in 1.3 > >>> since it's been around so long and deferred a couple times. Starting > >>> the discussion here is definitely the right way to make it happen. > > >>> That said, at the very least it needs a thorough code review, a full > >>> set of tests, and good documentation before it can be included. > > >>> I'm not personally sold on the way the functionality is implemented, > >>> but I'd have to think on what would be preferable. I'm sure others > >>> will have stronger opinions on it one way or the other. > > >>> All the best, > > >>> - Gabriel > > >>> On Oct 12, 9:47 am, alekam wrote: > >>> > Hi All, > > >>> > I found very useful ticket #8054. This ticket has accepted status and > >>> > assigned to brosher about 2 years. The problem describes on ticket > >>> > detail page and in the > >>> > wikihttp://code.djangoproject.com/wiki/ListColumns > >>> > The ticket has patch witch passes all existing regression tests and I > >>> > plan to write unit tests for it. > >>> > It is real to add ticket #8054 to 1.3 milestone? > > >>> > Cheers, > > >>> > Alex Kamedov > > >>> -- > >>> 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. > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: bu...@live.com -- 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: contrib.staticfiles app concerns
Hi Waldemar, Could you explain why is this should belong to django staticfiles app? This app has nothing to do with combining css files. It has one view (django.contrib.staticfiles.views.serve) in order to serve files in development. This is only a helper view used in development and I don't see why it is necessary to support css-combining solutions in it. If some app combines/compresses css/js files it should handle the path rewriting etc. and provide a way to insert the media into templates (e.g. via templatetag as django-compress do) because all these stuff can be handled in different ways. django.contrib.staticfiles (and it's serve view) doesn't stand in the way here and I think it's the best it could do. If django.contrib.staticfiles prevents something to be implemented then it's an another story and this should be fixed. On 27 окт, 16:24, Waldemar Kornewald wrote: > On Thu, Oct 21, 2010 at 10:10 PM, Waldemar Kornewald > > > > > > wrote: > > OK, I just went through django-mediagenerator to check if there's > > anything else needed by staticfiles and I noticed that we need to have > > a standard for URLs in CSS files (e.g., url(image.png)). > > > Since we don't know the STATICFILES_URL in our CSS code we have to use > > relative paths when referencing images. When CSS files get combined > > the resulting file is often in a different folder than its source > > files. This will break relative paths. Now we have these solutions: > > 1. keep URLs untouched when combining > > 2. rewrite URLs relative to source files > > 3. rewrite URLs relative to the combined file's path > > 4. rewrite URLs relative to STATICFILES_URL > > > URL rewriting would convert relative paths to absolute URLs beginning > > with STATICFILES_URL. > > > (1) is the easiest solution and it might be used by very simple asset > > managers. This approach is also used by quite a few CSS and JS > > frameworks (e.g. jQuery UI). Disadvantage: It only works if the > > combined CSS file is in the same location as its source files. > > > (2) is very intuitive because it behaves exactly like with uncombined > > files. Disadvantage: URL rewriting is inconsistent if you also support > > CSS compilers like Sass because the URLs used in imported files would > > be relative to the master file. This means imported files have to make > > assumptions about the master file's location which is very confusing > > and bad for reusability. > > > (3) is too confusing and makes too many assumptions about the combined > > file's location which is confusing and bad for reusability. > > > (4) is the most consistent solution. No matter whether you use a CSS > > compiler or normal CSS files or something else, URLs always behave the > > same. Disadvantage: At first you might expect different behavior, so > > it's quite not as intuitive as (2), but it's very easy to understand > > once you know what it does. Also, it doesn't have any of the > > disadvantages of (2). > > > IMHO, (4) is the best solution because it's consistent. (2) is the > > second best solution. It should be easy to adapt the code in > > django-mediagenerator and make a little patch for staticfiles, so it > > behaves like (4). What do you think? > > > In any case, staticfiles would need to rewrite URLs in its view, too. > > Otherwise we can't provide a consistent solution across all asset > > managers. > > Since this is pretty important and it would be great to have in the > alpha release, what do you need to be able to make a good decision, > here? > > Bye, > Waldemar -- 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: prepopulated_fields javascript error since r14123
On 27 October 2010 19:40, Andrew Godwin wrote: > On 27/10/10 07:01, Simon Meers wrote: > >> Has anyone else found that using prepopulated_fields in admin.ModelAdmin >> since r14123 produces a javascript error: "d.join is not a function"? >> > > I didn't get any errors when I tested the patch before commit - are you > having them on the 1.2.X backport, or the main trunk version? > On the 1.2.X backport; that sounds likely to be the reason it hasn't been picked up. -- 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: contrib.staticfiles app concerns
Hi Mikhail, On Wed, Oct 27, 2010 at 1:14 PM, Mikhail Korobov wrote: > Hi Waldemar, > > Could you explain why is this should belong to django staticfiles app? > This app has nothing to do with combining css files. It has one view > (django.contrib.staticfiles.views.serve) in order to serve files in > development. This is only a helper view used in development and I > don't see why it is necessary to support css-combining solutions in > it. If some app combines/compresses css/js files it should handle the > path rewriting etc. and provide a way to insert the media into > templates (e.g. via templatetag as django-compress do) because all > these stuff can be handled in different ways. > django.contrib.staticfiles (and it's serve view) doesn't stand in the > way here and I think it's the best it could do. If > django.contrib.staticfiles prevents something to be implemented then > it's an another story and this should be fixed. While it's true that staticfiles doesn't handle CSS-combining, many people will want to combine their files and thus use a different asset manager (potentially building on top of staticfiles; doesn't matter). If staticfiles doesn't set a standard here then different apps will depend on different (incompatible) URL rewriting schemes and this is bad for reusability. Staticfiles is supposed to prevent this. So, we need a standard here. Depending on which standard we choose it can have an influence on staticfiles and in order to be compliant with the standard we might have to rewrite URLs in staticfiles, too. Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/blog/django -- 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: It is real to add ticket #8054 to 1.3 milestone?
On Wed, Oct 13, 2010 at 12:47 AM, alekam wrote: > Hi All, > > I found very useful ticket #8054. This ticket has accepted status and > assigned to brosher about 2 years. The problem describes on ticket > detail page and in the wiki http://code.djangoproject.com/wiki/ListColumns > The ticket has patch witch passes all existing regression tests and I > plan to write unit tests for it. > It is real to add ticket #8054 to 1.3 milestone? I've looked at the wiki and ticket, and I'm having difficulty seeing what benefits this proposal offers. It looks to me like you're proposing to change the syntax that is used to declare list_display, but I can't really see any signficant changes in the flexibility of the new approach. As far as I can make out, everything you describe (and more) can already be achieved by using callables in list_display. This patch isn't going to get added to trunk just so we can add a new syntax for things we can already do. It needs to clearly add new capabilities that don't currently exist. 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: It is real to add ticket #8054 to 1.3 milestone?
Hi Mikhail, On Wed, Oct 27, 2010 at 5:45 PM, Mikhail Korobov wrote: > Hi Alex and Yuri, > > To make it clear: is this only a syntax change and all other benefits > can be achieved with current implementation? > > The benefits from the wiki: > > 1. ability to customize and localize 3rd-party application without > fork it - it is as easy with current ModelAdmin. ModelAdmin looks up > it's own methods so 'get_bar_column' in wiki can be put into > AccountAdmin. > > 2. ability to apply custom template filters on field value or model > method returned value without any magic - it is also possible: > template filters are just functions and @register.filter decorator > doesn't harm them. > > 3. ability to specify witch field will be used in order for column > based on model method - this is also totally possible with current > implementation > > 4. beautifully API to admin change list customization - as I can see > it is the only benefit here > > Am I correct and the goal is only to change list_display syntax? Yes, I don't see any other goal either, so I have controversial feelings about the issue. It has only syntax sugar, but that sugar is very sweet. > On 27 окт, 10:58, "burc...@gmail.com" wrote: >> Hi Alex, >> >> Patch is looking good, except few small things. >> Wiki docs are also very good, but they are quite incomplete. >> Replied to the ticket. >> >> >> >> >> >> On Tue, Oct 26, 2010 at 11:23 PM, Alex Kamedov wrote: >> > Can anybody rewiew the patch? >> >> > On Wed, Oct 13, 2010 at 6:35 PM, Alex Kamedov wrote: >> >> >> Hi All, >> >> I uploaded patch with tests and little improvements >> >> >>http://code.djangoproject.com/attachment/ticket/8054/8054-list-column... >> >> I think it ready for review. >> >> I really sorry, but I couldn't write good documentation because English >> >> isn't my own language. The maximum of my possibility in writing docs is >> >> here http://code.djangoproject.com/wiki/ListColumns For more examples >> >> see >> >> folder admin_listcolumn in regression tests provided by last my patch. >> >> Cheers, >> >> Alex Kamedov >> >> On Wed, Oct 13, 2010 at 2:12 AM, Gabriel Hurley wrote: >> >> >>> Hi alekam, >> >> >>> This is certainly the kind of ticket that we want to deal with in 1.3 >> >>> since it's been around so long and deferred a couple times. Starting >> >>> the discussion here is definitely the right way to make it happen. >> >> >>> That said, at the very least it needs a thorough code review, a full >> >>> set of tests, and good documentation before it can be included. >> >> >>> I'm not personally sold on the way the functionality is implemented, >> >>> but I'd have to think on what would be preferable. I'm sure others >> >>> will have stronger opinions on it one way or the other. >> >> >>> All the best, >> >> >>> - Gabriel >> >> >>> On Oct 12, 9:47 am, alekam wrote: >> >>> > Hi All, >> >> >>> > I found very useful ticket #8054. This ticket has accepted status and >> >>> > assigned to brosher about 2 years. The problem describes on ticket >> >>> > detail page and in the >> >>> > wikihttp://code.djangoproject.com/wiki/ListColumns >> >>> > The ticket has patch witch passes all existing regression tests and I >> >>> > plan to write unit tests for it. >> >>> > It is real to add ticket #8054 to 1.3 milestone? >> >> >>> > Cheers, >> >> >>> > Alex Kamedov >> >> >>> -- >> >>> 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. >> >> -- >> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, >> MSN: bu...@live.com > > -- > 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. > > -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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-
Re: Permission support for admin inlines
Hi, the permission checking should be doable if my ideas from http://groups.google.com/group/django-developers/browse_thread/thread/bfad2774ff7c357b# get in. So if someone can come up with a proper api as suggested by Russell I'd be happy to help codewise (this way we could even work around the DDN, as it leaves the user the choice to implement permission checks the way he wants to). Cheers, Florian -- 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: contrib.staticfiles app concerns
Why isn't it fine to have different URL rewriting schemes for
different assets bundlers?
E.g. if one uses django-compress he should list all files he wants to
combine in settings.py and then output them into template as {%
compressed_css 'my_css' %}. If one is using django-compressor then he
list all files he want to combine in template inside some other other
template tag. Then django-compress and django-compressor combine
files, store combined variants somewhere and provide correct urls for
stored files.
Why should one care if these files are stored and prepared the same
way in django-mediagenerator, django-compress and django-compressor or
not? Why should django.contrib.staticfiles care about this? There are
a lot of bundling apps now and they all already provide different
answers for this problem.
Please excuse me if I don't understand some obvious but I can't see a
point. As I can see, the purpose of django.contrib.staticfiles is to
collect media files from reusable applications in one place so that
developers of reusable application can rely on it and don't require
users to manually copy and update files from app source releases. It
also solves a problem of media files customizing - where to put
customized media files so that they can survive app upgrade. And
that's all. Why do you see django.contrib.staticfiles as a framework
for css/js combiners?
On 27 окт, 17:38, Waldemar Kornewald wrote:
> Hi Mikhail,
>
>
>
>
>
> On Wed, Oct 27, 2010 at 1:14 PM, Mikhail Korobov
> wrote:
> > Hi Waldemar,
>
> > Could you explain why is this should belong to django staticfiles app?
> > This app has nothing to do with combining css files. It has one view
> > (django.contrib.staticfiles.views.serve) in order to serve files in
> > development. This is only a helper view used in development and I
> > don't see why it is necessary to support css-combining solutions in
> > it. If some app combines/compresses css/js files it should handle the
> > path rewriting etc. and provide a way to insert the media into
> > templates (e.g. via templatetag as django-compress do) because all
> > these stuff can be handled in different ways.
> > django.contrib.staticfiles (and it's serve view) doesn't stand in the
> > way here and I think it's the best it could do. If
> > django.contrib.staticfiles prevents something to be implemented then
> > it's an another story and this should be fixed.
>
> While it's true that staticfiles doesn't handle CSS-combining, many
> people will want to combine their files and thus use a different asset
> manager (potentially building on top of staticfiles; doesn't matter).
> If staticfiles doesn't set a standard here then different apps will
> depend on different (incompatible) URL rewriting schemes and this is
> bad for reusability. Staticfiles is supposed to prevent this. So, we
> need a standard here. Depending on which standard we choose it can
> have an influence on staticfiles and in order to be compliant with the
> standard we might have to rewrite URLs in staticfiles, too.
>
> Bye,
> Waldemar
>
> --
> Django on App Engine, MongoDB, ...? Browser-side Python? It's
> open-source:http://www.allbuttonspressed.com/blog/django
--
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: Gentle Proposal: add 'render' shortcut in 1.3
Hi Ivan, Let me explain why I prefer 'border' middleware way (that is implemented) over explicit baking in messages middleware (that was implemented but then replaced with 'border' middleware). 1. 'Border' middleware is a backwards-compatible change, the requirement to bake response in middleware isn't. 2. With BakingMiddleware it is clear what middlewares expect responses to be baked and what expect responses to be unbaked. This provides practical benefits. If there is no BakingMiddleware and some middleware wants to change template or context it must call 'force_bake' (not just 'bake') to make sure the changes will apply. If there is an another middleware that want to change something (template or context) then template will be rendered several times. With BakingMiddleware the contract is a bit different. Template will be rendered exactly 1 time in this case because middleware can assume that the response was not baked. 3. The code behind BakingMiddleware should be executed anyway in order to prevent template rendering outside try-catch statements. The difference is only that you propose to execute 'bake' in the end of response cycle and I propose to execute it at the beginning of the response cycle but to make this customizable (by changing the position of the BakingMiddleware). On 27 окт, 13:33, Ivan Sagalaev wrote: > On 10/25/2010 04:33 PM, Russell Keith-Magee wrote: > > > * The problem with messages is a big one -- probably even a > > show-stopper if we can't find a way to reconcile the general use case > > that it represents (i.e., we don't just need a fix for > > contrib.messages -- we need to explain how/why the problem exists, > > and provide a consistent approach for analogous problems) > > I apologize in advance if I missed some important bits of the > conversation I'm on vacation right now :-). > > Why can't we teach messages middleware to just explicitly bake a > response and call it a proper solution? By adding `force_bake` to the > HttpResponse class itself we effectively declare that *any* HttpResponse > can be lazy and middleware that expects some side-effects from a > response has to bake it. > > Sure it must be documented that middleware forcing response baking > should work after the ones that don't. -- 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: contrib.staticfiles app concerns
2010/10/27 Mikhail Korobov :
> Why isn't it fine to have different URL rewriting schemes for
> different assets bundlers?
OK, sorry for not having explained it well. What I mean is this:
Imagine this code snippet in a reusable app's CSS file:
/* myapp/style.css */
div.icon {
background-image: url(img/icon.png);
}
Now this file gets combined into "css/main.css". Depending on which
asset manager and URL rewriting scheme you use the URL can be:
1. unmodified: "img/icon.png"
2. relative to the current file: "/static/myapp/img/icon.png"
3. relative to the combined file: "/static/css/img/icon.png"
4. relative to STATICFILES_URL "/static/img/icon.png"
If one developer who uses an asset manager based on (2) publishes a
reusable app and another developer who uses an asset manager based on
(4) publishes a reusable app there is no way to put both apps into
your project and have both work correctly with the same asset manager.
Note, in practice, (1) and (3) have pretty much the same result.
Anyway, (1) and (3) would be very bad ideas if you want to support
combined files, so let's leave them out of this discussion.
(2) is what everyone is used to, but it's inconsistent if you use Sass
or other CSS compilers because they allow importing other files which
might also contain URLs and there's no way for the asset manager to
rewrite URLs relative to the imported file's path (the asset manager
only gets one big result file which already contains all imported
files). This inconsistency is annoying e.g. when you develop both with
CSS and Sass.
(4) is fully consistent and easy to understand, but obviously behaves
differently from what most people are used to when developing .
However, this way all URLs look the same, no matter if you use Sass or
CSS or both.
(1), (2), and (3) would already be compatible with the current
staticfiles implementation. (4) would require a little modification.
I've seen (1), (2), and (4) used in practice when combining CSS files.
Which behavior should be the standard for all asset managers?
Bye,
Waldemar
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django
--
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: Gentle Proposal: add 'render' shortcut in 1.3
Hmm, and now I don's see a use case for the 'force_bake' (and maybe even public 'bake' method) method if BakingMiddleware is implemented. With BakingMiddleware there is exactly one place where response should be baked and user's code shouldn't be calling 'force_bake' and even 'bake' on responses. On 27 окт, 19:55, Mikhail Korobov wrote: > Hi Ivan, > > Let me explain why I prefer 'border' middleware way (that is > implemented) over explicit baking in messages middleware (that was > implemented but then replaced with 'border' middleware). > > 1. 'Border' middleware is a backwards-compatible change, the > requirement to bake response in middleware isn't. > > 2. With BakingMiddleware it is clear what middlewares expect responses > to be baked and what expect responses to be unbaked. This provides > practical benefits. If there is no BakingMiddleware and some > middleware wants to change template or context it must call > 'force_bake' (not just 'bake') to make sure the changes will apply. If > there is an another middleware that want to change something (template > or context) then template will be rendered several times. With > BakingMiddleware the contract is a bit different. Template will be > rendered exactly 1 time in this case because middleware can assume > that the response was not baked. > > 3. The code behind BakingMiddleware should be executed anyway in order > to prevent template rendering outside try-catch statements. The > difference is only that you propose to execute 'bake' in the end of > response cycle and I propose to execute it at the beginning of the > response cycle but to make this customizable (by changing the position > of the BakingMiddleware). > > On 27 окт, 13:33, Ivan Sagalaev wrote: > > > > > On 10/25/2010 04:33 PM, Russell Keith-Magee wrote: > > > > * The problem with messages is a big one -- probably even a > > > show-stopper if we can't find a way to reconcile the general use case > > > that it represents (i.e., we don't just need a fix for > > > contrib.messages -- we need to explain how/why the problem exists, > > > and provide a consistent approach for analogous problems) > > > I apologize in advance if I missed some important bits of the > > conversation I'm on vacation right now :-). > > > Why can't we teach messages middleware to just explicitly bake a > > response and call it a proper solution? By adding `force_bake` to the > > HttpResponse class itself we effectively declare that *any* HttpResponse > > can be lazy and middleware that expects some side-effects from a > > response has to bake it. > > > Sure it must be documented that middleware forcing response baking > > should work after the ones that don't. -- 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: Django on Google App Engine via SQL (not nonrel)
Hi Wesley, Maybe it would also be helpful to point out in advance what known behaviors (often considered as limitations) of the datastore will be carried to the MySQL compatibility layer that Django would have to deal with. For example, currently using GQL counting the number of rows returned by a query is/was really tricky because of the 1000 rows limit. I also recall there was a 1 MB limit on the size of every item you could store. I've collected some links regarding this kind of stuff that I'm including here: http://aralbalkan.com/1504 http://stackoverflow.com/questions/421751/whats-the-best-way-to-count-results-in-gql http://stackoverflow.com/questions/264154/google-appengine-how-to-fetch-more-than-1000 http://stackoverflow.com/questions/703892/whats-your-experience-developing-on-google-app-engine http://blog.burnayev.com/2008/04/gql-limitations.html Hope this help a bit discuss this matters, Antonio Lima-Peru -- 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: Bump/question for #13956
Thanks for the suggestion. I've added tests for the inclusion tags, so now everything is being tested that I could think of - with the exception of inclusion tags that have takes_context=True. Really, though, they should act the same way from the tag's point of view. The only difference is that if the first argument of the tag is not called 'context', the tag compilation function should raise a TemplateSyntaxError. But that happens when the tag is registered, so it seems like it ought to be tested elsewhere if it isn't already. -- 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.
More efficient negative lookups
Hi all, I'd like to fix an inefficiency in our ORM's negative lookups. A long, long time ago, we had an "ne" lookup for QuerySet.filter(), which would let us do "not equals" lookups, like this: MyModel.objects.filter(slug__ne='ignoreme') Unfortunately, we removed this lookup type in http://code.djangoproject.com/changeset/2422 -- four and a half years ago. (Wow, have we really been around that long!?) The excuse at the time was that we added QuerySet.exclude() and that made "ne" lookups redundant. Problem is, that's technically not true, because "ne" generated SQL that was more efficient than what exclude() currently generates. Specifically, the problem is that the exclude() SQL doesn't take advantage of indexes on mycolumn as efficiently as the old-style lookup. Here's the difference: -- Old-style ne lookup SELECT * FROM mytable WHERE mycolumn != 'foo'; -- exclude() SELECT * FROM mytable WHERE NOT (mycolumn = 'foo'); Cal Henderson talked about this in his DjangoCon presentation. See slide 30 here: http://www.slideshare.net/iamcal/why-i-hate-django-part-22-presentation It's also at 41:46 in the video: http://www.youtube.com/watch?v=i6Fr65PFqfk I'd like for Django to go back to the more efficient query here, instead of the lame "NOT" query. Two solutions come to mind: we can restore the "ne" lookup type, or we can change the exclude() implementation to generate "!=" in the underlying SQL if possible. The advantage of the former is that it's much simpler to implement, but the advantage of the latter is that any code currently using exclude() would get the benefit of faster queries. (Note that I imagine only people using exclude() with a single "exact" lookup parameter would get the benefit; we could get trickier beyond that, but...diminishing returns.) We could also do both. I'm inclined to say we do the former -- restore the "ne" lookup type -- because it's a quick fix, and ask somebody to write up a patch for the latter. Does anybody have strong opinions against this? If not, I can restore the "ne" lookup type. Adrian -- 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: More efficient negative lookups
On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: > I'm inclined to say we do the former -- restore the "ne" lookup type > -- because it's a quick fix, and ask somebody to write up a patch for > the latter. Does anybody have strong opinions against this? If not, I > can restore the "ne" lookup type. Sounds like a good plan to me (especially making simple excludes faster). However, just for the record I think the reason we decided to remove __ne is the first place was that its existence introduces a weird inconsistency with regard to other lookup types. That is, if there's a "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down that path lies madness so I'm +0 on bringing back "ne" with the proviso that we agree it's not the first step down a slippery slope towards "nistartswith" and friends. Jacob -- 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: More efficient negative lookups
On Wed, Oct 27, 2010 at 5:55 PM, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: >> I'm inclined to say we do the former -- restore the "ne" lookup type >> -- because it's a quick fix, and ask somebody to write up a patch for >> the latter. Does anybody have strong opinions against this? If not, I >> can restore the "ne" lookup type. > > Sounds like a good plan to me (especially making simple excludes faster). > > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends. > > Jacob > > -- > 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. > > I'd be -0.5 (let's see how pusillanimous I can be!) on introducing __ne, but +1 on fixing the internals to generate proper not equal comparisons. 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: More efficient negative lookups
On Wed, Oct 27, 2010 at 4:55 PM, Jacob Kaplan-Moss wrote: > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends. Totally agree we should set clear expectations that "ne" does not mean we'll be getting nistartswith or any other negative lookup -- good call in bringing that up. This should be treated as a special case for a common case. Adrian -- 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: More efficient negative lookups
On Oct 27, 5:55 pm, Jacob Kaplan-Moss wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty wrote: > > I'm inclined to say we do the former -- restore the "ne" lookup type > > -- because it's a quick fix, and ask somebody to write up a patch for > > the latter. Does anybody have strong opinions against this? If not, I > > can restore the "ne" lookup type. > > Sounds like a good plan to me (especially making simple excludes faster). > > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends. I know it's been a little while since I've made any major ORM contributions, but I'd say -0 on __ne, and +1 on making exclude generate better code. Django's worked far too hard on making things consistent as possible to let like this slip by just because we don't want to muddy our hands with a little harder work in the exclude() code. So many other tickets have been stuck in DDN/Accepted forever because the area of code is harder to review, it's not like it's an unknown state in the project. :) I'd even be willing to throw my hat in the ring to contribute towards an .exclude()-based solution if someone else doesn't step forward, but I know I won't be touching it until a few days pass. George -- 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: contrib.staticfiles app concerns
Hi Waldemar,
On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
wrote:
> 2010/10/27 Mikhail Korobov :
>> Why isn't it fine to have different URL rewriting schemes for
>> different assets bundlers?
>
> OK, sorry for not having explained it well. What I mean is this:
> Imagine this code snippet in a reusable app's CSS file:
>
> /* myapp/style.css */
> div.icon {
> background-image: url(img/icon.png);
> }
>
> Now this file gets combined into "css/main.css". Depending on which
> asset manager and URL rewriting scheme you use the URL can be:
> 1. unmodified: "img/icon.png"
> 2. relative to the current file: "/static/myapp/img/icon.png"
> 3. relative to the combined file: "/static/css/img/icon.png"
> 4. relative to STATICFILES_URL "/static/img/icon.png"
>
> If one developer who uses an asset manager based on (2) publishes a
> reusable app and another developer who uses an asset manager based on
> (4) publishes a reusable app there is no way to put both apps into
> your project and have both work correctly with the same asset manager.
>
> Note, in practice, (1) and (3) have pretty much the same result.
> Anyway, (1) and (3) would be very bad ideas if you want to support
> combined files, so let's leave them out of this discussion.
>
> (2) is what everyone is used to, but it's inconsistent if you use Sass
> or other CSS compilers because they allow importing other files which
> might also contain URLs and there's no way for the asset manager to
> rewrite URLs relative to the imported file's path (the asset manager
> only gets one big result file which already contains all imported
> files). This inconsistency is annoying e.g. when you develop both with
> CSS and Sass.
>
> (4) is fully consistent and easy to understand, but obviously behaves
> differently from what most people are used to when developing .
> However, this way all URLs look the same, no matter if you use Sass or
> CSS or both.
(4) is no good because you might have file name conflicts when used
with multiple reusable applications.
Why haven't you mentioned this problem?
> (1), (2), and (3) would already be compatible with the current
> staticfiles implementation. (4) would require a little modification.
> I've seen (1), (2), and (4) used in practice when combining CSS files.
>
> Which behavior should be the standard for all asset managers?
I think, in a compressor, you shouldn't rely on STATICFILES_URL but on your own
DJANGO_MEDIAGENERATOR_FILES_URL and DJANGO_MEDIAGENERATOR_FILES_ROOT,
which can be set up to implement necessary strategy from (1)-(4).
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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: contrib.staticfiles app concerns
Hi Yuri,
On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com wrote:
> Hi Waldemar,
>
> On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
> wrote:
>> 2010/10/27 Mikhail Korobov :
>>> Why isn't it fine to have different URL rewriting schemes for
>>> different assets bundlers?
>>
>> OK, sorry for not having explained it well. What I mean is this:
>> Imagine this code snippet in a reusable app's CSS file:
>>
>> /* myapp/style.css */
>> div.icon {
>> background-image: url(img/icon.png);
>> }
>>
>> Now this file gets combined into "css/main.css". Depending on which
>> asset manager and URL rewriting scheme you use the URL can be:
>> 1. unmodified: "img/icon.png"
>> 2. relative to the current file: "/static/myapp/img/icon.png"
>> 3. relative to the combined file: "/static/css/img/icon.png"
>> 4. relative to STATICFILES_URL "/static/img/icon.png"
>>
>> If one developer who uses an asset manager based on (2) publishes a
>> reusable app and another developer who uses an asset manager based on
>> (4) publishes a reusable app there is no way to put both apps into
>> your project and have both work correctly with the same asset manager.
>>
>> Note, in practice, (1) and (3) have pretty much the same result.
>> Anyway, (1) and (3) would be very bad ideas if you want to support
>> combined files, so let's leave them out of this discussion.
>>
>> (2) is what everyone is used to, but it's inconsistent if you use Sass
>> or other CSS compilers because they allow importing other files which
>> might also contain URLs and there's no way for the asset manager to
>> rewrite URLs relative to the imported file's path (the asset manager
>> only gets one big result file which already contains all imported
>> files). This inconsistency is annoying e.g. when you develop both with
>> CSS and Sass.
>>
>> (4) is fully consistent and easy to understand, but obviously behaves
>> differently from what most people are used to when developing .
>> However, this way all URLs look the same, no matter if you use Sass or
>> CSS or both.
> (4) is no good because you might have file name conflicts when used
> with multiple reusable applications.
> Why haven't you mentioned this problem?
Which conflict do you mean? If you want to refer to some app's image
from "app/css/style.css" you'd use "app/img/icon.png" with (4) and
"../img/icon.png" with (2). Each path with (4) maps to exactly one
path with (2) and the other way around, so any conflict that applies
to (4) also applies to (2).
>> (1), (2), and (3) would already be compatible with the current
>> staticfiles implementation. (4) would require a little modification.
>> I've seen (1), (2), and (4) used in practice when combining CSS files.
>>
>> Which behavior should be the standard for all asset managers?
>
> I think, in a compressor, you shouldn't rely on STATICFILES_URL but on your
> own
> DJANGO_MEDIAGENERATOR_FILES_URL and DJANGO_MEDIAGENERATOR_FILES_ROOT,
> which can be set up to implement necessary strategy from (1)-(4).
Whether URLs are rewritten with STATICFILES_URL or
DJANGO_MEDIAGENERATOR_FILES_URL doesn't make a real difference for
this discussion. I'm fine with either setting, but let's first focus
on the general URL rewriting solution, please.
Bye,
Waldemar
--
Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
http://www.allbuttonspressed.com/blog/django
--
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: Gentle Proposal: add 'render' shortcut in 1.3
On 10/27/2010 04:55 PM, Mikhail Korobov wrote: 1. 'Border' middleware is a backwards-compatible change, the requirement to bake response in middleware isn't. The difference is only that you propose to execute 'bake' in the end of response cycle and I propose to execute it at the beginning of the response cycle but to make this customizable (by changing the position of the BakingMiddleware). I understand your points now, thanks. Two things bother me about 'border' middleware: - its semantics is a bit different than that of others middleware in the list in settings and this difference is not explicitly clear when looking at the list - it's bad to have a boilerplate code that people just have to put somewhere I've spent a night with a thought and now I think I can propose even better solution. We can introduce a new kind of middleware — "template response middleware" for lack of a better name. A user who wants to do something with a template response *before* it is baked has to write a middleware like this: class ContextInjectionMiddleware: def process_template_response(self, request, response): # do something with response Request handling code would look like this then: response = get_response(...) if hastattr(response, 'force_bake'): # apply template response middleware response.force_bake() # apply normal response middleware This way we: - are getting rid of force_bake in HttpResponse where it's a noop - maintain backward compatibility since response is baked before all currently written middleware - require explicitly named method to deal with a new concept What's not to like? :-) -- 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.
