rethinking raw_id_fields
sub...@gmail.com
I was browsing the tickets and saw a few of them nagging about some
restrictions to raw_id_fields. That they are limited to other objects
registered in admin, that they are limited arbitrarily (relative to a
regular FK) by the permissions of the user, etc. Personally, I find
the little changelist window that pops up a bit awkward and hackish-
looking.
Might a better approach be to have a django-admin view which uses
content-types to generate a list of the objects in question? If
someone can give me a simple yes, no, etc, I'd be willing to do the
necessary ticket-work and come up with a patch for review.
bur...@gmail.com
why not just replace them with some proper implementation of ajax completion ?
http://djangopackages.com/grids/g/auto-complete/
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
sub...@gmail.com
-Steve
On Sep 30, 3:07 am, "burc...@gmail.com" <burc...@gmail.com> wrote:
> Hi Subsume,
>
> why not just replace them with some proper implementation of ajax completion ?
>
> http://djangopackages.com/grids/g/auto-complete/
>
bur...@gmail.com
> At that point its not really raw_id_fields, is it? =)
After all, what's the purpose of these fields?
sub...@gmail.com
are reluctant to use AJAX. If introducing AJAX into admin is fine,
dumping these fields altogether seems the best approach.
As for the options given, I've only used ajax-selects. I think its
implementation is rather cumbersome in situations where I didn't
really care about what the resulting list looked like (if I just
wanted a list of the objects represented by whatever is in their
__unicode__).
So a starting admin equivalent might look like: ajax_fields =
{'person': ['first_name','last_name']}. The list in this case is the
search_fields which kind of mirrors admin's current functionality. Or
maybe I'm getting ahead of myself.
-Steve
On Sep 30, 2:21 pm, "burc...@gmail.com" <burc...@gmail.com> wrote:
sub...@gmail.com
tyrion-mx
Autocomplete,
here's the code: http://bitbucket.org/tyrion/django
and here's a live demo (without css for the autocomplete, so it looks
kinda ugly): http://djangoac.tyrion.mx/admin/ login with test/test.
Let me know what you think about it.
bur...@gmail.com
Multicomplete have no add item button with popup.
This is usually the hardest thing to implement with such control,
because it's rendered *after* the control.
Was it that hard to subclass widgets as Admin*AutocompleteWidget and
add required css media from jquery.ui to them?
Lots of other features are missing, that can be found in mature implementations:
add new item with permission checking (
http://code.google.com/p/django-ajax-selects/ ),
field dependencies (http://github.com/digi604/django-smart-selects is
the best here),
custom querysets & concept of autocomplete channels (
http://code.google.com/p/django-ajax-selects/ or mine
http://github.com/buriy/django-extrafields/tree/master/extrafields/autocomplete/
) ,
queryset caching & setting autocomplete properties (
http://code.google.com/p/django-autocomplete ).
--
bur...@gmail.com
Anyway, I'd like to see notes from core devs regarding adding such
feature to Admin interface (so please don't say -1 if you think it's
just not mature enough!).
Or maybe all interested parties should work on some kind of
django-admin-extensions instead of improving admin itself.
Actually, it seems there is still no consensus in the django community
of what ideal admin interface should look like.
It's very controversial question!
I remember django core devs repeatedly said that django.contrib.admin
should be simple, and they intends it should be useful only for few
use-cases like observing your data, adding at most few initial model
instances, editing users and permissions, and being example of how to
(not) create reusable django application with UI, and how to create
poll application with no use of db explorer like phpmyadmin.
Different people tried to say many times that admin instead should be
extensible and have all sort of features to be really useful.
How do you see django admin in 5 years? This is the question to be
asked first of all.
Personally, I see django admin completely outside of django project in
5 years, like django debug toolbar and the rest, and I'd say, django
core team time should use their time to review and apply patches, fix
bugs and add new features to django itself, so admin development
should be stopped, admin docs must contain: "admin app is not much
useful -- we just don't have enough time to add features into it, and
we don't think we should do this -- but it can be used as an example
for django beginners of how (not) to do reusable django applications".
On Fri, Oct 1, 2010 at 5:45 AM, tyrion-mx <tyri...@gmail.com> wrote:
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
sub...@gmail.com
I'm not really in favor of overthinking this too much--I think a
satisfactory replacement for raw_id_fields is good enough (adequately
encompasses all the features). I know there are a lot of mature
projects out there when it comes to AjaxFields and I don't think its
up to django.contrib.admin to compete with them--they are there to use
and can easily be integrated into admin for those who require advanced
features.
As for the big picture of admin in 5 years, its certainly a good
question but I'm not sure that its 'the question to be asked first of
all'. Overthinking like this stalls tickets, sometimes indefinitely.
Please don't think I'm trying to hinder discussion. I just don't think
making an absolute answer to that discussion a contingency of this
called-for feature.
-Steve
> > Let me know what you think about it.
>
> > --
> > You received this message because you are subscribed to the Google Groups "Django developers" group.
> > To post to this group, send email to django-d...@googlegroups.com.
> > To unsubscribe from this group, send email to django-develop...@googlegroups.com.
sub...@gmail.com
"I just don't think making an absolute answer to that discussion a
There we go.
Marcob
> Hello all,
> I was browsing the tickets and saw a few of them nagging about some
> restrictions to raw_id_fields.
used this patch:
http://code.djangoproject.com/ticket/7028
I see that mtrs wrote an improved version.
I also see that at each new Django release a fixed version comes up
after few days (if not few hours).
I think it is a huge improvement in user experience and I never fully
understood why it always missed each django release since 1.0.
Now I see that another improved patch comes up concerning also M2M:
http://code.djangoproject.com/ticket/13221
Well, M2M and raw_id_fields are a big player in wonderful admin
contrib with a poor interface: why do not improve them?
Ciao.
Marco.
Russell Keith-Magee
> On 30 Set, 07:34, "subs...@gmail.com" <subs...@gmail.com> wrote:
>> Hello all,
>> I was browsing the tickets and saw a few of them nagging about some
>> restrictions to raw_id_fields.
>
> Since my first Django installation, a couple of years ago, I fixed and
> used this patch:
> http://code.djangoproject.com/ticket/7028
>
> I see that mtrs wrote an improved version.
> I also see that at each new Django release a fixed version comes up
> after few days (if not few hours).
> I think it is a huge improvement in user experience and I never fully
> understood why it always missed each django release since 1.0.
The reason that #7028 hasn't been included is the same reason that any
other ticket hasn't been included -- time. We have finite resources.
We can only fix a certain number of tickets if we want to keep a
timely release schedule.
As good as the ideas in #7028 are, they're not absolutely essential -
we've lived without the feature for a long time, and there's no data
loss at stake. As a result, it's been sacrificed in the interests of
other tickets.
#7028 is also subject to another major impediment -- it's dealing with
an area that requires front-end expertise. From my personal
perspective, I'm hesitant to get involved in anything touching the
front end out of lack of knowledge. I don't profess to being a UX
expert, and I'm certainly not an expert at CSS. I don't have the
facilities to do rigorous testing on any platform other than OSX. So -
even thought this ticket has been on my radar for a while, the barrier
for entry for me is higher than it is for other tickets.
Yours,
Russ Magee %-)
sub...@gmail.com
effectively deprecates raw_id_fields?
I'm interested in seeing a ticket like #14370 go forward if only to
close a slew of dusty old tickets about raw_id_fields.
-Steve
Chuck Harmston
sub...@gmail.com
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
Marcob
> An Ajax admin solution (of the autocomplete sort, which I presume is what
> you're proposing) does not have the same use case for raw_id_fields. 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.
I usually tweak the link to open a popup already filtered and such
things.
Ciao.
Marco.
Chuck Harmston
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
sub...@gmail.com
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.
>
>
>
>
>
>
> > 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-d...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > .
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> Chuck Harmston
> *
> ch...@chuckharmston.comhttp://chuckharmston.com