Re: Improving ForeignKeyRawIdWidget (raw_id_fields in admin)

[Simon Meers]

On 13 June 2013 07:41, Simon Meers <drme...@gmail.com> wrote:

> On 13 June 2013 03:33, <rich...@richard.ward.name> wrote:
>
>> I think that the usability of ForeignKeyRawIdWidget could be vastly
>> improved if the representation part of the widget (the object name, in
>> bold) were to be updated when a new object gets chosen. I think this could
>> be done relatively easily with a small change introducing little extra
>> complexity.
>>
> The handling of raw IDs, particularly in a comma-separated list for
> many-to-many relationships, is arguably the biggest user-facing "wart" in
> the current admin implementation. The sheer number of available related
> objects often makes listing the full set in a dropdown or other widget
> unfeasible, forcing developers to resort to the raw ID mechanism to a)
> improve efficiency in terms of database-querying and response/DOM-size, and
> b) make the selection interface manageable and allow
> searching/filtering/pagination/etc. Providing a textual representation of
> the object as per the standard widgets makes sense here.
>

Julien Phalip has recently put a new patch together for this -- see
https://code.djangoproject.com/ticket/7028#comment:74 -- reviews would be
greatly appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: RedirectView supporting View-Names

[Simon Meers]

See https://code.djangoproject.com/ticket/15273


On 23 November 2012 23:30, Ludwig Kraatz  wrote:

> Hi,
>
> is there a specific reason why the RedirectView does not have a
> "view_name" attribute and out-of-the-box supporting to reverse it?
>
>   if self.url:
>  url = self.url
>   elif self.view_name:
>  url = reverse(self.view_name, kwargs=kwargs, request=request)
>   else:
>  return None
>
> best regards
> ludwig
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/YaZrSyhb7fEJ.
> To post to this group, send email to django-developers@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-developers@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: Python 3: should we apply unicode_literals everywhere?

[Simon Meers]

It's a shame we couldn't skip straight to Python 3.3 and take
advantage of PEP414...

On 22 August 2012 07:32, Adrian Holovaty  wrote:
> On Tue, Aug 21, 2012 at 5:46 AM, Aymeric Augustin
>  wrote:
>> In my opinion, option (2) is a logical move at this point. However I
>> believe it deserves a public discussion (or at least an explanation).
>> What do you think?
>
> I prefer option 2 as well, because it seems like the Right Thing To
> Do. Of course, there's no rush to do everything -- we can just nibble
> off bits here and there.
>
> I'll have some free time soon and would be happy to help out migrating
> code. (Relatively) mindless refactoring like this is one of my
> favorite things to do. :-)
>
> 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-developers@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-developers@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: Python 3 - style question

[Simon Meers]

> On 10 August 2012 18:56, Vinay Sajip  wrote:
>> I think Option 2 is better, for the reasons you state.

+1. And it's not too entangled to be easily stripped out if/when
Python 2 support is removed.

On 11 August 2012 06:10, Łukasz Rekucki  wrote:
> How about wrapping those 3 lines of code into a class decorator
> (preferably named more explicit then StrAndUnicode) ? That would be at
> least a little DRY.

+1. It won't mess with the inheritance hierarchy, and is explicit
enough (depending on the name), whilst encapsulating the boilerplate
elegantly. @python2_unicode_compatible?

(Though, @-syntax class decorators are only available from 2.6+, but
I'm guessing we won't be able to drop 2.5 support at the same time as
picking up 3. I guess we could just tidy up when we do.)

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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 Sprint at PyCon Australia 2012 -- Monday 20th August

[Simon Meers]

Monday 20th August 0900-2359 AEST at PyCon Australia 2012 (Hobart) [1]

The Interaction Consortium [2] have kindly offered to provide pizza
and beer (presumably only for those physically present ;)

Join us via the #django-sprint IRC channel on Freenode; see [3] for
more information.

[1] http://2012.pycon-au.org/programme/sprints
[2] http://interaction.net.au
[3] https://code.djangoproject.com/wiki/Sprints

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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.

ModelForm.Meta.overrides

[Simon Meers]

A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm
violently -1 on the whole topic "meta programming form fields after they've
been instantiated", it's a mess. Yes it would be more DRY, but also much
harder to know how the hell the form fields are composed as. Just override
the form field, it's not a huge deal code wise and much easier to grok." This
has since been contested [2] (though for invalid reasons in my opinion).

I'm not sure that Jannis and I were talking about the same thing; the
solution I had in mind did not involve changing form-fields after their
instantiation, but rather providing a more elegant and flexible mechanism
that works in a similar way to ModelForm.Meta.widgets and
formfield_callback.

I've put a draft patch together and attached it to [1] which should give a
better indication of the intended approach and its flexibility and
benefits. There are still a few details to iron out in evolving the ideal
implementation, but this at least demonstrates the gist of it. Does anyone
else think this is worth exploring?

Simon

[1] https://code.djangoproject.com/ticket/17924
[2] *
https://groups.google.com/d/msg/django-developers/x_nJ5epfG18/ZSKcPW0_DvAJ*

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Allow changing form field properties after form creation

[Simon Meers]

On 6 April 2012 07:26, Beres Botond  wrote:
> Hi Chris,
>
> Isn't it this what you are trying to do?
>
> class DocumentForm(ModelForm):
>        def __init__(self, *args, **kwargs):
>                super(MyForm, self).__init__(*args, **kwargs)
>                self.fields['title'].required = False
>
> Which works perfectly fine. You can tweak pretty much any property at
> runtime like that, without replacing the field entirely.

This discussion is sounding more like something that belongs in
django-users. I agree that there are some improvements that can be
made to make field-tweaking easier and more elegant, as proposed in
[1] which Keryn pointed out in [2]. It would probably be better to
continue this conversation in those tickets.

Simon

[1] https://code.djangoproject.com/ticket/17924
[2] https://code.djangoproject.com/ticket/18064

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: ModelBackend should have a get_anonymous_user method

[Simon Meers]

Hi Ric,

On 18 November 2011 19:53, Ric  wrote:
> ...
> i've created a ticket
> https://code.djangoproject.com/ticket/17254

Thank you for your contributions of late. Please note that you don't
need to email django-developers when you create a new ticket; we
receive notifications through django-updates and monitor Trac.

Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: type-field model inheritance

[Simon Meers]

Hi Carl,

> FWIW, django-model-utils [1] includes an InheritanceManager that
> implements polymorphic queries in a single query via select_related.

Ah, there goes my theory that I thought of it first :) And of course
introspection of subclasses via the reverse OneToOne descriptors is
perfect.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: type-field model inheritance

[Simon Meers]

On 4 March 2011 17:03, Craig de Stigter  wrote:
> Hi guys
>
> Thanks for pointing those out. I knew I couldn't have been the first to want
> this. I guess I just didn't know the right words to search for here.
> It looks like django_polymorphic does what I want. I'm not yet sure why it
> says it takes one query per type of model in a queryset. Unless it is
> talking about multi-table inheritance, in which each type would require a
> different join. But I'll look in more detail in the next few days and no
> doubt it will become clear.

+1 for better polymorphic support in Django core; it is a very common
problem which could do with an efficient and elegant solution.
Regarding efficiency, if you can keep track of your subclasses
effectively (potentially using a registry if not introspection), you
can use select_related to retrieve heterogeneous multi-table
inheritance models in a single query (see example in [1]). I haven't
looked deeply enough into django_polymorphic to see if it includes
such optimisations. I'm sure we could further tweak the internals to
make things more efficient and developer-friendly in this regard.

Cheers,
Simon

[1] http://stackoverflow.com/q/5175009/284164

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Feature request: Abstract ManyToManyField

[Simon Meers]

2011/2/5 Carl Meyer 
>
> Hi Mike,
>
> On Feb 3, 4:36 pm, Mike Lindsey  wrote:
> > I'm doing something with bidirectional ManyToManyFields, in a project
> > I'm working on, that is resulting in duplicate attempts to create the
> > intermediate tables.  I'm perfectly open to suggestions of "You're
> > doing it wrong" if they come with advice on how to fix my problem,
> > without losing the easy Admin insertion of the relationships (without
> > resorting to InLines, which don't seem to play nicely at all with
> > FieldSets).  Right now I'm getting around the problem by running
> > syncdb, running dbshell to drop the table it complains about, and
> > rerunning syncdb; repeating until syncdb finishes successfully.
> >
> > What would make this exceptionally easy, is if there was the option to
> > set 'abstract=True' on second iteration of each of the
> > ManyToManyFields, telling syncdb to not attempt to create it.
>
> So what you're trying to do here is simply not supported. I'm guessing
> you've already concluded as much. This means that, for now, there is
> no good answer for you (that I'm aware of). Whatever hack or
> workaround you are able to come up with is what you're gonna get.
> Sorry.

BTW the ticket for this is #897 [1] and there is a suggested
workaround (explicit declaration of the 'through' table) which isn't
*too* ugly and might help you in the short-term?

Simon

[1] http://code.djangoproject.com/ticket/897

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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: Need advice on ticket #14928 (manage runserver does not allow host name as address)

[Simon Meers]

> I don't know how many people actually used that feature (I never did),
> but it seems like it was a bit accidental. As we are speaking about a
> development server, I don't find this feature very useful as (most of
> the time) you want to run it on a host-only address, which won't have
> many aliases other than "localhost". You could add more in your
> "hosts" file or have a DNS on intranet map to your machine, but it
> sounds like a really rare case.
>

I actually use this all the time; my /etc/hosts has an entry for almost
every Django project I work on; this way the browser maintains separate
cookies for each one, so I don't have to keep logging in/out, etc. I'd be
very disappointed to see this functionality disappear.

Simon

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

[Simon Meers]

On 30 October 2010 07:50, Andrew Godwin  wrote:

>
>  It's working fine for me on my freshly-updated 1.2.X branch - did you make
> sure the caches were clear, etc, etc?
>


Yes, and I'd experienced it on several different
servers/projects/client-machines. Yet I've just tested it on a new project
also, and it seems to be fine, as you say. I've discovered that in one of
the projects someone had set up a
"templates/admin/prepopulated_fields_js.html" template (why?!) which
contained the old javascript join code! No idea what the cause was on the
other projects, but I'm guessing the core code is fine; sorry for the
confusion.

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

[Simon Meers]

On 27 October 2010 19:40, Andrew Godwin <and...@aeracode.org> 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.

prepopulated_fields javascript error since r14123

[Simon Meers]

Has anyone else found that using prepopulated_fields in admin.ModelAdmin
since r14123 produces a javascript error: "d.join is not a function"?

-- 
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: Permission support for admin inlines

[Simon Meers]

On 27 October 2010 08:15, Simon Litchfield  wrote:

> The ModelAdmin's permission hooks are great- has_add_permission,
> has_change_permission, and has_delete_permission.
>
> It would be nice if they were supported by inlines in the same way; ie
> InlineModelAdmin, StackedInline, TabularInline, GenericStackedInline,
> GenericTabularInline.
>
> UI is fairly obvious; has_add would result in no add form; has_delete
> in no delete tick box; and for has_change, showing as readonly_fields
> would probably be easiest.
>
> Any thoughts?
>
>
This should be considered together with the question of whether the user's
general permissions should apply to inlines [1], which is in DDN at present.

[1] http://code.djangoproject.com/ticket/8060

-- 
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: #3400 -- ModelAdmin.list_filter improvements

[Simon Meers]

Anyone? I know it is a relatively complex patch to review, but it would be a
shame to see such a frequently requested feature/fix miss the 1.3 boat.

On 29 August 2010 08:06, Simon Meers <drme...@gmail.com> wrote:

> A gentle reminder to anyone who would like to review the recent patch
> uploaded for #3400 [1].
>
> I have come across quite a number of people who consider list_filter's
> current inability to span relationships (e.g. as search_fields can) to be
> one of the more obvious/annoying of Django's limitations and would love to
> see it implemented.
>
> [1] http://code.djangoproject.com/ticket/3400
>

-- 
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: Something.is_live instead of implementation specific is_live settings

[Simon Meers]

If everything is under version control, you'll need to detect the server
status somehow. Some options:
- check the absolute path of the settings file on the filesystem if you can
ensure this path is different on the production server
- import socket; and check socket.gethostname()
- check for "runserver" in sys.argv
- etc.

On 25 September 2010 06:50, Yo-Yo Ma  wrote:

>
> What if I want dev settings in version control?
>
> What if I want "explicit"?
>
>
> On Sep 24, 11:09 am, "burc...@gmail.com"  wrote:
> > How it's better from both of the following:
> >
> > 1)
> > try:
> > from dev_settings import *
> > except ImportError:
> >pass
> >
> > 2)
> > if DEBUG:
> > from dev_settings import *
> >
> > Because to have "project.is_dev" you'll have to write it somewhere
> already!
> >
> > It's bootstrapping problem.
> >
> >
> >
> >
> >
> > On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma 
> wrote:
> > > I read that article. The problem is that it's deployment specific. I
> > > dint even know what host name "omh.cc" is, but I have a feeling that
> > > you couldn't work on that from your laptop to your desktop without
> > > changing something. What I propose isn't a is_production variable. I'm
> > > proposing an explicit is_development variable so that I can choose my
> > > settings "explicitly" instead of trying to import something and then
> > > something else if that's not there. That is very un-pythonic. If I can
> > > say something to the effect of:
> >
> > > if project.is_dev:
> > >import dev_settings
> > > else:
> > ># is live
> >
> > > just example. I'm not suggesting "project" as a global. It's just to
> > > show the type of setting I want.
> >
> > > That's much cleaner, and far more explicit than "import os, socket,
> > > etc".
> >
> > > On Sep 23, 7:41 pm, Yo-Yo Ma  wrote:
> > >> Thanks for the link David. I'm gonna check it it now.
> >
> > >> On Sep 23, 6:16 pm, "David P. Novakovic" 
> > >> wrote:
> >
> > >> > This link and the comments suggest some good stuff... particularly
> the
> > >> > comment from Malcolm and the original post.
> >
> > >> >
> http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
> >
> > >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
> >
> > >> >  wrote:
> > >> > > The thing is, in production mode you normally have to define where
> > >> > > your settings are anyway, so you pass the unusual settings file
> name
> > >> > > there, and just use the regular settings.py for your development.
> >
> > >> > > So then you are passing the settings configuration information
> once in
> > >> > > the production server's configuration, not every time you run your
> > >> > > development server.
> >
> > >> > > I think people with any decent sized project have addressed this
> issue
> > >> > > in their own way that suits their own needs.
> >
> > >> > > For example we have lots of settings files and just import the
> > >> > > relevant settings into a final file.
> >
> > >> > > For testing I do what i mentioned in my previous email.
> >
> > >> > > Like anything on here, you need to ask whether what you are
> suggesting
> > >> > > would actually be better off as part of the core or if it works
> just
> > >> > > fine as something that people can choose to use themselves...
> >
> > >> > > I think most people use whatever system they are happy with and it
> > >> > > doesn't get in the way of deployment/development. Thus this fails
> to
> > >> > > meet one of the critical requirements for consideration for
> inclusion
> > >> > > into core.
> >
> > >> > > D
> >
> > >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <
> baxterstock...@gmail.com> wrote:
> > >> > >> Thanks David, but I'm talking about having something built in.
> For
> > >> > >> instance, passing a variable to the "Development" server to tell
> it
> > >> > >> you're in "Development" seems a bit redundant, no?
> >
> > >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" <
> davidnovako...@gmail.com>
> > >> > >> wrote:
> > >> > >>> As for running different configs:
> >
> > >> > >>> manage.py runserver --settings=settings_test
> >
> > >> > >>> etc..
> >
> > >> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss <
> ja...@jacobian.org> wrote:
> > >> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma <
> baxterstock...@gmail.com> wrote:
> > >> > >>> >> I'm simply proposing the idea of having the development
> server
> > >> > >>> >> explicitly set something to indicate a "in development"
> status, so
> > >> > >>> >> that if that does not exist you can make the assumption that
> the
> > >> > >>> >> project is live.
> >
> > >> > >>> > This is exactly what the settings.DEBUG flag is for. Use it.
> Love it.
> >
> > >> > >>> > Jacob
> >
> > >> > >>> > --
> > >> > >>> > You received this message because you are subscribed to the
> Google Groups "Django developers" 

Actions in popups

[Simon Meers]

Users regularly get confused when you present them with a raw_id popup
window which shows action checkboxes beside the list of items they are
selecting from -- they try to click the checkboxes, and wonder why the
window isn't closing. IMHO it really doesn't make much sense to be
performing actions within the context of a popup selection window anyway,
though I'm no UXpert. A search on trac revealed [1].

Opinions?

[1] http://code.djangoproject.com/ticket/11700

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

#3400 -- ModelAdmin.list_filter improvements

[Simon Meers]

A gentle reminder to anyone who would like to review the recent patch
uploaded for #3400 [1].

I have come across quite a number of people who consider list_filter's
current inability to span relationships (e.g. as search_fields can) to be
one of the more obvious/annoying of Django's limitations and would love to
see it implemented.

[1] http://code.djangoproject.com/ticket/3400

-- 
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: Why this feature is still not accepted ?

[Simon Meers]

Apart from permissions issues etc as Mikhail mentioned, there is also an
important design decision required about whether it is a good idea to
provide a dynamic link to the selected item rather than the last saved item.
If you allow the user to change their selection and then click the link to
view that item, you're encouraging them to follow a link which will lose
their unsaved changes. I think it is wiser to provide a clear (named) link
to the saved item.

Interesting that this ticket did not come up as a duplicate when #13165 [1]
was opened. I suggest the earlier ticket should be closed as a duplicate,
since #13165 has a more mature/up-to-date patch. It is just awaiting
resolution of permission issues and the input of a UX expert, together with
#13163 [2]

Simon

[1] http://code.djangoproject.com/ticket/13165
[1] http://code.djangoproject.com/ticket/13163


On 7 August 2010 04:46, dharmesh.patel.eif...@gmail.com <
dharmesh.patel.eif...@gmail.com> wrote:

> Hello,
>
> http://code.djangoproject.com/ticket/11397
>
> As I already implemented it for Django version1.1 but still there is
> no action or feedback on it.
>
> --
> 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: postgresql last_insert_id issue

[Simon Meers]

The patch here [1] fixes this if anyone feels like reviewing. This bug is
preventing me from using trunk on several projects at present, so it would
be great to get the patch checked in. It also fixes a number of other
problems people have been reporting, I believe.

Simon

[1] http://code.djangoproject.com/ticket/13821


On 29 July 2010 03:19, ryan_peaceworks  wrote:

> Hi,
>
> I'm running trunk and I found an issue where my model's tablename
> contains uppercase characters.
>
> svn praise says this broke in r13363
>
> r13363   russellm # Use pg_get_serial_sequence to get the
> underlying sequence name
> r13363   russellm # from the table name and column name
> (available since PostgreSQL 8)
> r13363   russellm cursor.execute("SELECT
> CURRVAL(pg_get_serial_sequence('%s','%s'))" % (table_name, pk_name))
>
> The issue is that table_name is not double-quoted when necessary.
>
> Probably the string argument should be self.quote_name(table_name)
> rather than just table_name.
>
> --
> 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: natural keys and dumpdata

[Simon Meers]

> I'll put it on my todo list; if anyone else wants to give it a sanity
> check, I'd appreciate the extra eyeballs.

Looks pretty sane to me, though I wonder if the deserialisation should
raise an exception if the pk is missing and an incomplete set of
natural key fields is provided? Nice work, thanks Chris.

-- 
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: Feature Request

[Simon Meers]

On 22 June 2010 19:59, Massimiliano della Rovere <
massimiliano.dellarov...@gmail.com> wrote:

> Anyway using this method I can't sort columns any more.
> This is why I was suggesting having links created by the framework:
> callable aren't sortable.
>

They can be -- set admin_order_field on the callable [1]

[1]
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display

-- 
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: Feature Request

[Simon Meers]

On 21 June 2010 17:49, Massimiliano della Rovere
 wrote:
> If I understood correctly, these patches are related to the change view of
> the instance, not to che change list view (the page where instances are
> listed).

Correct; I interpreted your request for "the change page of the linked
object" to be the "change" page for the instance, not the "changelist"
for the model.

-- 
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: Feature Request

[Simon Meers]

> EmailField, UrlField, Foreign Key, OneToOneField and ManyToManyField
> clickable in the admin changelist interface of Django 1.3:
> if you click you are redirected to:
>  - Foreign Key, OneToOneField and ManyToManyField: the change page of
> the linked object

This is already implemented in the patch for #13163 [1] and #13165 [2]
(though ManyToMany seemed a bad idea). Plus screenshots [3].

[1] http://code.djangoproject.com/ticket/13163
[2] http://code.djangoproject.com/ticket/13165
[3] http://share.simonmeers.com/django_related_changelinks/

-- 
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 Related-Object Links in Admin

[Simon Meers]

>>  * Permissions - from my initial inspection, it isn't obvious to me
>> that you are honoring (and/or testing that you are honoring)
>> permissions. If I don't have permission to edit an object, I shouldn't
>> get an edit link. Given the addition in 1.2 of object-level
>> permissions, this means permissions need to be per-object. Have I
>> missed something in my hasty patch read?
>
> Correct; no permissions checking is performed at present. In some
> places checking would be almost impossible given the current code
> architecture, so I had hoped to avoid it if possible. This was one of
> the main points I wanted feedback on.

Here is a more detailed explanation of why permission checking has
been omitted for now:

* The "add-another" link (green plus) next to ForeignKey widgets is
appended to the HTML output in the render() method. This currently has
no access to the User, so cannot determine permissions. The
"add-another" link (and new "edit" link) will therefore be displayed
regardless of the current user's add/change permissions for the
related object. This should certainly be dealt with, but this ticket
does not appear to the the appropriate place to do so. Ticket #1035
[1] addresses this issue.

* The "edit separately" links on inlines could perform checking using
a templatetag, perhaps. Again, however, I'm not sure that this is the
place to deal with this as larger issues exist -- currently a user can
add/change inlines even if they do not possess permissions for the
inline model. Ticket #8060 [2] addresses this issue.

So the current patch for #13163 and #13165 [3] seems to solve the
issues in a manner which fits with the rest of the admin interface as
it currently stands. Permission issues should certainly be dealt with,
but separately I believe. I think [3] could be committed as is
(pending review), and permission controls added as the other tickets
are resolved. Currently all this means is that people might see an
edit link, click on it, then get a "permission denied" message --
though in the relatively rare cases where a related object is
registered in the same admin site but the user doesn't have permission
to change it.

IMHO the UX improvements in [3] are worth getting on board ASAP.

Simon


[1] http://code.djangoproject.com/ticket/1035
[2] http://code.djangoproject.com/ticket/8060
[3] 
http://code.djangoproject.com/attachment/ticket/13163/combined_13163_13165.diff

-- 
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: Admin patches

[Simon Meers]

Hi Sebastian,

> Btw, running the test suite with mysql takes forever.
> If you know the reason please tell me. However i was able to run the
> test suite on a plain django 1.2.1 installation with sqlite, but got 11
> failures and 37 errors ...

Have you read [1]? Do you still get errors if you run:
./runtests.py --settings=test_sqlite
from the tests/ directory?

Did you also know you can run any desired subset of tests? E.g.:
./runtests.py --settings=test_sqlite admin_inlines admin_views
--
Ran 145 tests in 29.500s

Simon

[1] 
http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests

-- 
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 Related-Object Links in Admin

[Simon Meers]

> The demo screenshots you provide certainly look good to me; I haven't
> done a full teardown on the patch, but a from a quick glance it
> certainly looks promising.

Thanks for your response Russ.

>  * Why allow edit links on a readonly field? This seems a little
> redundant to me?

Because whilst the field on that model might be read-only, the related
object itself is not necessarily. In fact in most cases I've found
that this is the case.

>  * On the edit link for ForeignKey (localhost:8000 in your example),
> I'd be inclined to stick to just "edit", not "edit " -- that
> seems more consistent with the other edit links you have provided.

But then if you select a different object, "edit" looks like it refers
to the selected one instead of the original. I could have used
JavaScript here to select the dynamically chosen object, but in the
absence of a popup link this would be pointless -- you choose a
different ForeignKey value, then leave the page to edit it thinking
you've saved the value...

>  * I take it that the widget edit links carry through to inlines?
> i.e., if i have a foreign key pulldown in an inline, I will get the
> edit link?

Yes.

>  * How does performance degrade when JavaScript is not available? Do
> the links exist at all, or do they become dangling links to the wrong
> object?

Solid as a rock; does not use JavaScript.

>  * In the case of raw-id fields and inlines, is there any reason why
> the edit link is separate text, rather than the object name itself
> being the link? (ie., rather than "John smith ", why
> not just ""?

Yes; because you're already editing John smith, but if you want to
edit him separately you can go elsewhere to do so with a (probably
more detailed) dedicated form.

>  * Permissions - from my initial inspection, it isn't obvious to me
> that you are honoring (and/or testing that you are honoring)
> permissions. If I don't have permission to edit an object, I shouldn't
> get an edit link. Given the addition in 1.2 of object-level
> permissions, this means permissions need to be per-object. Have I
> missed something in my hasty patch read?

Correct; no permissions checking is performed at present. In some
places checking would be almost impossible given the current code
architecture, so I had hoped to avoid it if possible. This was one of
the main points I wanted feedback on.

Simon

-- 
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 Related-Object Links in Admin

[Simon Meers]

On 25 May 2010 07:50, Simon Meers <drme...@gmail.com> wrote:
>
> I've uploaded some screenshots [1] of the new patch for #13163 [2] and
> #13165 [3] in action, to allow people to see the affect without
> necessarily applying the changes.
>
> These enhancements have *vastly* improved the navigability of the
> admin interface between related objects.
>
> Please have a look and let me know if you have concerns or suggestions
> for improvement. The design decisions are documented in the tickets.
>
> [1] http://share.simonmeers.com/django_related_changelinks/
> [2] http://code.djangoproject.com/ticket/13163
> [3] http://code.djangoproject.com/ticket/13165


I'm guessing DjangoCon.eu week wasn't the ideal time to send this.
Loads of people did check the screenshots out though. Anyone have
concerns or suggestions?

-- 
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: www.djangoproject.com down?

[Simon Meers]

http://downforeveryoneorjustme.com/djangoproject.com

On 1 June 2010 17:23, Vinay Sajip  wrote:

> I've been having trouble accessing www.djangoproject.com recently,
> from here in the UK. Is this a known problem? Is the server down?
>
> Regards,
>
> Vinay Sajip
>
> --
> 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.

#11882 Ready for checkin?

[Simon Meers]

I was today momentarily caught out by the missing documentation for
formfield_for_manytomany, and found #11882 [1] which has a patch for
this very issue and was marked "Ready for checkin" last year. It's a
shame it missed 1.2 Anyone care to give it a push?

[1] http://code.djangoproject.com/ticket/11882

-- 
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 Related-Object Links in Admin

[Simon Meers]

I've uploaded some screenshots [1] of the new patch for #13163 [2] and
#13165 [3] in action, to allow people to see the affect without
necessarily applying the changes.

These enhancements have *vastly* improved the navigability of the
admin interface between related objects.

Please have a look and let me know if you have concerns or suggestions
for improvement. The design decisions are documented in the tickets.

[1] http://share.simonmeers.com/django_related_changelinks/
[2] http://code.djangoproject.com/ticket/13163
[3] http://code.djangoproject.com/ticket/13165

-- 
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: Trac Full!

[Simon Meers]

> I was trying to figure out why I was getting Internal Server Errors
> when attempting to upload a patch on code.djangoproject.com -- I have
> discovered that there is "no space left on the device"!

This seems to be fixed now (thank you webmaster). However it may be
worth noting that the email address on the 500 message is apparently
invalid:

Delivery to the following recipient failed permanently:

webmas...@djangoproject.com

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.1.1
: Recipient address rejected: User
unknown in local recipient table (state 14).

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

Trac Full!

[Simon Meers]

I was trying to figure out why I was getting Internal Server Errors
when attempting to upload a patch on code.djangoproject.com -- I have
discovered that there is "no space left on the device"!

Now you can't even add a comment to the database:

Traceback (most recent call last):
  File "/home/trac/trac/web/main.py", line 406, in dispatch_request
dispatcher.dispatch(req)
  File "/home/trac/trac/web/main.py", line 237, in dispatch
resp = chosen_handler.process_request(req)
  File "/home/trac/trac/ticket/web_ui.py", line 290, in process_request
self._do_save(req, db, ticket)
  File "/home/trac/trac/ticket/web_ui.py", line 558, in _do_save
cnum=internal_cnum):
  File "/home/trac/trac/ticket/model.py", line 250, in save_changes
(self.id, when, author, cnum, comment))
  File "/home/trac/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
  File "/home/trac/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
ProgrammingError: could not extend relation 1663/24784/3185145: No
space left on device
HINT:  Check free disk space.

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

Display link to change-form on inlines where model is registered in admin site

[Simon Meers]

I've just submitted #13163 [1] with a patch to display a link to the full
change-form for inlines of models which are registered in the same admin
site, similar to the existing "view on site" link for inlines. I have had
numerous projects where this would have been immensely useful (for which I
had to create hacked copies of the full inline templates).

I know we're in 1.2 bugfix, so feel free to leave this until later.
Otherwise:
- Is this change useful/minor enough to include in 1.2?
- Does anyone know of cases where this behaviour should be disabled (see
ticket)?

Simon

[1]: http://code.djangoproject.com/ticket/13163

-- 
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: Bug in Form metaclass?

[Simon Meers]

Thanks for looking into this Russ

> Firstly, django-dev isn't "second tier tech support" - if you don't
> get an answer on django-users for a user-space question, that's a
> pity, but it doesn't mean you can or should "escalate" to django-dev.

I realise this; I thought this was the place to discuss potential
bugs, but thought I'd better throw some sanity checks out elsewhere
before I did.

> Doesn't look like a bug. Subclassing AuthenticationForm works for me,
> and I can't find any way to make your test case fail in the way you
> describe.

I thought I was going crazy when I tried again just now and couldn't
reproduce it myself! Thankfully I tracked the problem down to
importing django via a symlink in the project directory to the
appropriate version. If I remove the symlink and let it import django
from elsewhere in the pythonpath, it works as expected.

$ cat test.py
from django.contrib.auth.forms import AuthenticationForm
from django import forms

class MyForm(AuthenticationForm):
extra_field = forms.BooleanField()

print MyForm().fields.keys()
$ ./manage.py validate
['username', 'password', 'extra_field']
0 errors found
$ ln -s /media/d/Development/django/django-trunk/django/
$ ./manage.py validate
['username', 'password']
0 errors found

Odd. I've never encountered any other problems when using a local
symlink to django; everything else seems to operate fine.

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

Bug in Form metaclass?

[Simon Meers]

Disclaimer: Just in case this was a naive mistake on my part, I posted
this on django-users first [1] and posed the question several times on
#django, but have received no answers.

#
# forms.py:
#
    from django import forms
    class TestForm(forms.Form):
        test_field = forms.BooleanField()
#

#
# test.py:
#
    # import the same class from two different locations:
    from project_name.forms import TestForm
    from project_name.some_module.forms import TestForm as TestForm2

    class MyForm(TestForm):
        extra_field = forms.BooleanField()

    print MyForm().fields.keys()
    # prints: ['test_field', 'extra_field'] as expected

    class MyForm2(TestForm2):
        extra_field = forms.BooleanField()

    print MyForm2().fields.keys()
    # prints: ['test_field']
    # extra fields not registered if superclass imported from other app/module!
#

Python 2.6.4, Django SVN-12401

Is this a bug? The same happens if you try to import, say,
django.contrib.auth.forms.AuthenticationForm and subclass it. Surely
I'm missing something here?

Simon

[1] 
http://groups.google.com/group/django-users/browse_thread/thread/b4b4ddd684b352e1

-- 
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: Suggestion: DictionaryField

[Simon Meers]

I had considered designing something like this last week. It does seem to be
a common requirement -- any situation where a simple field would be almost
suitable but for the fact you'd like to avoid duplicates and allow fast
selection of existing values. A Field shortcut could be commonly used to
avoid the creation of separate models. Another example:

class Suburb(models.Model):
name = models.CharField(max_length=64, unique=True)

class Meta:
ordering = ['name']

def __unicode__(self):
return u'%s' % self.name


class School(models.Model):
name = models.CharField(max_length=64, unique=True)

class Meta:
ordering = ['name']

def __unicode__(self):
return u'%s' % self.name


class Student(models.Model):
school = models.ForeignKey(School)
suburb = models.ForeignKey(Suburb)
# ...

could be replaced with simply:

class Student(models.Model):
school = models.DictionaryField(max_length=64)
suburb = models.DictionaryField(max_length=64)
# ...

I'm not 100% sold on the name, but I think it is on the right track. I'm
also wondering whether it could be worth catering for types other than
CharField as well. For example:

team_number = models.DictionaryField(type=models.IntegerField)

This makes me wonder whether perhaps this could be generically applied to
all fields via a Field.__init__ kwarg instead:

class Student(models.Model):
school = models.CharField(max_length=64, lookup=True)
suburb = models.CharField(max_length=64, lookup=True)
team_number = models.IntegerField(lookup=True)

Either way, these fields could then be stored in separate tables
appname_modelname_fieldname, with a single field of the appropriate type
(named 'value' or similar). It would be nice to also provide external access
to these auto-generated models via something like Student.school.objects.
Currently Student.school would be a ReverseSingleRelatedObjectDescriptor,
and objects can be accessed via
Student.school.field.related.parent_model.objects.all(), but a shortcut
would be nice.

The auto-generated models could provide ordering by value, a unique
constraint on the field, and a simple __unicode__ method like the examples
above.

Simon


2010/1/17 Михаил Лукин 

> Well, the simplest way is making DictionaryField more like CharField,
> except that it's values will be stored in separate table. For example
> (application name is "hardware", engine is sqlite3), if I define
>
> *class HDD(models.Model):
>   form_factor = DictionaryField(max_length=10)
>   capacity = models.FloatField()
> *
> there will be 2 tables generated:
>
> *CREATE TABLE "hardware_hdd_form_factor_dict" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor" varchar(10) NOT NULL UNIQUE
> )
> CREATE TABLE "hardware_hdd" (
> "id" integer NOT NULL PRIMARY KEY,
> "form_factor_id" integer NOT NULL REFERENCES
> "hardware_hdd_form_factor_dict" ("id"),
> "capacity" real NOT NULL
> )
>
> * I guess, field constructor should not accept "unique" argument as it
> make no sense.
> I see 2 ways of rendering such field on a form:
> 1) usual  with autocompletion;
> 2)  +  + (maybe) radio buttons
> as it should be allowed to choose from existing and to create new
> dictionary item.
>
-- 

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.