Yes, I use that. Inside my formfield_for_foreignkey() method I
instantiate my special widget. My widget contains a render() method
that generates javascript that makes an ajax request that requests the
options for the select. There is no way to prune down the selections
with formfield_for_foreignkey(), in such a way that the selections are
different for different objects.
For example, for my Task object, I have
class TaskAdmin(admin.ModelAdmin:
def formfield_for_foreignkey(self, db_field, request, **kwargs):
if db_field.name == "owner":
kwargs["widget"] = OwnerSelectWidget(db_field.rel)
return db_field.formfield(**kwargs)
return super(TaskAdmin, self).formfield_for_foreignkey
(db_field, request, **kwargs)
However, in the changelist view, different tasks have different sets
of potential owners. IE, a task that is for the foo project can have
bob, joe, or mark as an owner. But a task that is for the bar project
can have jane, mary, or ann as an owner. There is no way to implement
this with just formfield_for_foreignkey(), because that method is for
*all* Task objects and is executed at a point in the django source
where there is no knowledge of what particular task is being
rendered. What I am trying to do is make it so that when the user
clicks on the owner field for the foo task, they have the choice of
bob, joe, or mark, and when they clock on the owner field for the bar
task, they have the choice of jane, mary, or ann. The Task has a
resources field, and that identifies the possible resources (which can
be the owner) for the task. So when the user clicks on the owner
field, the ajax request gets the resources for the particular task and
fills the drop down selections with them.
I have pasted a copy of my OwnerSelectWidget, as well as the above
code at http://dpaste.com/47694/. Maybe that will make it more
clear.
I don't know - maybe my needs are unusual. It's definitely not your
standard blog app ... so if I am too much on the outskirts for this to
be something that we consider in the development community, I can
understand that. But it seems to me that having a dynamic (ie, object
based) way to pair down options in a drop down would be something that
would be useful to others. And while I have a solution here, it was
pretty tough to get to and required a lot of studying and stepping
through the source code.
Anyway, hope the problem I am trying to solve and the solution I have
posted are understandable. Would love to hear from those in the
development community as to whether you think this is a wortwhile
addition.
Margie
On May 25, 7:29 pm, Justin Lilly <justinli...@gmail.com> wrote:
> 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 Developerhttp://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
-~----------~----~----~----~------~----~------~--~---
