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 the owner of task 'n', how to get my new widget's jquery/javascript to send 'n' as an argument to the callback method. I did manage to do this in javascript by finding the id of my owner field (ie, id_form-3- 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 is one. 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 specified method. 2) give the app-developer more control of the showAddAnotherPopup. Is this the right place for this discussion? If not, what is? Margie On May 25, 3:11 am, Zain Memon <z...@inzain.net> wrote: > 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-... > > Also, I've set up a GitHub repo for my work until official svn branches are > handed out. You can follow my progress > here:http://github.com/zain/django/tree/master > > Zain > > ----------------------------------- > My GSoC > proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
