Righton. I haven't used it too intensely for filtering and sorting but I do have some other thoughts about that.
1) Would it be better to come up with a non-changelist changelist for raw_id_fields. I find myself avoiding raw_id_fields because I don't necessarily want to register the object in question in the admin and give change permissions. Also, the current resulting pop-up of a changelist window is very displeasing to me and seems really just kind of hacked together. Having the actions dropdown among other things confuses things. I guess in this case one couldn't avoid registering it in admin (or could we, and provide a default which uses the unicode?). 2) Does anyone think there would be any advantage to 'flatten' raw_id_fields? Essentially, it would become a non-javascript link that would bring up a changelist which leads us back to the original changelist and autopopulates it? Screen-reading software is rather ambiguous when it comes to the current usability flow (aka I have had user complaints). The problem is pretty well outlined here: http://webaim.org/techniques/javascript/other#popups (I autocompleted on google to find that :). -Steve On Oct 4, 9:56 am, Chuck Harmston <ch...@chuckharmston.com> wrote: > We're playing semantic leapfrog here, but I don't see the proposed Ajax > solution as "searching", I see it as "autocompleting"; people won't use it > to discover content, they will use it as a shortcut for accessing content > that they are familiar with. As I said, much of the utility of the > raw_id_fields popup is that it allows content discovery, which is an > important use case—not all admin users will be perfectly familiar with the > content. > > I am in full favor of an Ajax autocomplete widget (which, as I said, already > exists in the admin-ui branch), but do not want it to replace raw_id_fields; > their uses cases are completely disparate. > > On Mon, Oct 4, 2010 at 12:05 AM, subs...@gmail.com <subs...@gmail.com>wrote: > > > > > > > With the AJAX field implementation on the table you're free to > > represent the objects however you want. Yeah, there's a few things > > left out but did you really say 'no searching'? > > > -Steve > > > On Oct 3, 10:09 pm, Chuck Harmston <ch...@chuckharmston.com> wrote: > > > it's based on the assumption that the user knows the value of the unicode > > > representation of the object. It does not allow for discovery like the > > > raw_id_fields popup does: no filtering, no sorting, no searching, and no > > > browsing. I am a strong -1 this. > > > -- > > 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<django-developers%2Bunsubscr > > i...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-developers?hl=en. > > -- > * > Chuck Harmston > * > ch...@chuckharmston.comhttp://chuckharmston.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-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.
