On Wednesday, August 7, 2013 11:51:58 PM UTC+2, DrMeers wrote: > > On 13 June 2013 07:41, Simon Meers <[email protected] <javascript:>> wrote: > >> On 13 June 2013 03:33, <[email protected] <javascript:>> wrote: >> >>> I think that the usability of ForeignKeyRawIdWidget could be vastly >>> improved if the representation part of the widget (the object name, in >>> bold) were to be updated when a new object gets chosen. I think this could >>> be done relatively easily with a small change introducing little extra >>> complexity. >>> >> The handling of raw IDs, particularly in a comma-separated list for >> many-to-many relationships, is arguably the biggest user-facing "wart" in >> the current admin implementation. The sheer number of available related >> objects often makes listing the full set in a dropdown or other widget >> unfeasible, forcing developers to resort to the raw ID mechanism to a) >> improve efficiency in terms of database-querying and response/DOM-size, and >> b) make the selection interface manageable and allow >> searching/filtering/pagination/etc. Providing a textual representation of >> the object as per the standard widgets makes sense here. >> > > Julien Phalip has recently put a new patch together for this -- see > https://code.djangoproject.com/ticket/7028#comment:74 -- reviews would be > greatly appreciated. >
Hi DrMeers, As I commented <https://code.djangoproject.com/ticket/7028#comment:78> in the ticket #7028, this new patch needs some work. I tried to figure out a solution for inlines but there are too much ramifications for me. Anyway, I think a better approach to the problem is a reusable app (usable inside and outside the admin). Into contrib or not. There are some apps around : https://www.djangopackages.com/grids/g/auto-complete/ I have tested django-autocomplete-light because it got a lot of contributions and claimed to be production ready. Unfortunately it was broken when I tested it against one of my project (infamous UnicodeEncodeDecodeError exception). I should have tried to contribute to that very project but I choose to not. The main reasons being: 1. I am in a hurry for a #7028 remplacement. 2. I need something reliable. 3. I want to *pip install* in production, not to clone a fork of a git repo and *python setup.py install etc*. So I started a *really* light app - django-yaaac - you can find on Github<https://github.com/Starou/django-yaaac>and Pypi <https://pypi.python.org/pypi/django-yaaac/0.92.5>. I can't say it is production-ready / stable, but it is ready for my productions ! Ticket #7028 should be closed in my opinion. Cheers, Stanislas. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/10ee55c0-a0a8-4c6f-8303-a76f84b73afd%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
