I think that foreign key selection in the admin interface is a great
area to be putting cycles into. I've played around with Jannis
Leidel's foreign key autocomlete widget and am familiar with that, I
think you are modeling your stuff after that, is that right? While I
think that is a cool widget, I find that the real problem with foreign
key selection in the admin is that there is no easy way to prune down
the set of choices. If one has a lot of choices, autocomplete is not
really a help, especially if you don't know the choice names. For
example, in the app I am developing (a task management system), I have
tasks and owners of tasks. The owner of the task can be user in the
system, and there are 6000+ users.
What I would really like to see is foreign key selection widget where,
when the end-user clicks on the foreign key selection dropdown, it
sends an ajax request back to the server to execute a app-developer-
specified method that returns a queryset, and the results of this
queryset would then get placed into the select options for the foreign
key selection drop down.
I have proof-of-concept code that I have implemented and would be
happy to provide the code I have. While developing this code, I
wrestled extensively with a couple problems. One is described in a
bug I posted on Friday: http://code.djangoproject.com/ticket/11183
The render function for my widget initially renders just a single
choice for the selections - the choice that is the currently selected
owner. The reason I override the default queryset from inside render
() is that the default queryset in my case would the 6000+ users. It
seemed silly to send 6000+ selection options when they would get
replaced on the user's click. Keep in mind this widget also gets used
in the changelist view, so the 6000 option selections would be sent
for each object in the changelist view (and there can be many).
Anyway, when overriding the selection in render(), I encountered
problems in the core django datastructurse that made this not work -
this is the bub described in 11183.
The second problem I wrestled with was how to pass the id of the
currently displayed object to the my get_owner_queryset() callback
method. IE, from the changelist view, when the user tries to change
to send 'n' as an argument to the callback method. I did manage to do
owner) and replacing "owner" with "id", and then sending the value of
that field. This of course depends on there being a field that is
id_form-3-id whose value is the id of the object being displayed. I
would like to find a better way to do this, but I don't know if there
Anyway, perhaps some will say that I am trying to use the admin
interface for more than it was intended for. But I have been
impressed with how much the admin can do for me, and I would really
like to use it because as it gets extended, I feel I can really
benefit from those extensions. However, I find the inability to give
the user a viable way to choose foreign keys to be a real show
stopper. In the same vein, I think that there should be a way to
configure the behavior of the little green '+', (showAddAnother
popup). To use my task/owner example again - when the user is
choosing a task owner, I wouldn't ever want the user to be able to
add another user. I want them to be able to choose different owners
without being able to add new users.
Of course I can do all of this myself - and I have been working
(slowly) towards that end. But as a relatively experienced user, my .
02 regarding the admin interface and foreign keys is that it would be
a huge benefit to:
1) provide an interface that allows the app-developer to prune down
the choices for a foreign key via an ajax callback to an app-developer
2) give the app-developer more control of the showAddAnotherPopup.
Is this the right place for this discussion? If not, what is?
On May 25, 3:11 am, Zain Memon <z...@inzain.net
> Since GSoC officially started a couple of days ago, I've implemented a rough
> draft of an autocomplete widget for foreign keys in the admin.
> You can see a screenshot and a short write-up of the functionality on my
> blog here:http://inzain.net/blog/2009/05/a-foreign-key-autocomplete-widget-for-.