Not entirely sure if this is what you were referring to, Margie, but
you can limit a the queryset used for an admin dropdown (FK). Code
for this looks something like:
# defined in the ModelAdmin for this class.
def formfield_for_foreignkey(self, db_field, request=None, **kwargs):
field = super(HomepageAdmin,
self).formfield_for_foreignkey(db_field, request=None, **kwargs)
if db_field.name == 'promo_story':
field.queryset =
Article.objects.filter(id__in=Article.objects.all()[:100])
return field
Also, if you want this specifically in relation to an FK autocomplete,
you should be able to implement that in the view that returns your
results.
-justin
On Mon, May 25, 2009 at 9:26 PM, Margie <margierogin...@gmail.com> wrote:
>
> 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/
> >
>
--
Justin Lilly
Python/Django Developer
http://justinlilly.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-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
-~----------~----~----~----~------~----~------~--~---
