Hi Richard,

As the last maintainer of the patch of the ticket #7028, I am happy to see 
you bring that one on the table!

What the patch does is to add the unicode representation of the related 
object next to the input field (the unicode value is sent back by the pop 
up.)
It also works for the ManyToMany fields.
It has not been merged in the trunk so far, a lack of manpower and tests I 
presume (there are some, but nothing that guarantee the good Javascript 
behaviour on different web browsers).

I also have some code that do the Ajax autocompletion for in-house projects 
and started to think about how to improve #7028 with an auto-complete 
feature (Ajax or not, but a cached solution has a big performance penalty 
imo.)

There is another ticket on the subject, #14370 but I don't really like the 
solution, sorry :-)

The ideas:

- Admin should benefit of an autocomplete solution beside raw_id_fields 
without any external dependancies ;
- That autocomplete functionality should be officially reusable outside the 
admin ;
- This should works without having to register() stuff or declare 
settings.AUTOCOMP_MEDIA_DIR, at least for the default behaviour.
- The raw_id_fields we know should still works the same, especially for 
non-javascript users.


I know and understand that core-devs are going to scream but a 
*contrib.autocomplete 
*app seems to be a good option, isn't?
And admin should auto-magically (or not) turn raw_id_fields in autocomplete 
ones if the app is in INSTALLED_APPS.

Cheers,

--
Stan

On Wednesday, June 12, 2013 7:33:31 PM UTC+2, [email protected] 
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.
>
> At present the original representation remains, which is confusing to 
> users and could lead to mistakes being made.
>
> I think this can't be done simply by a 3rd party app without some 
> seriously dirty monkey patching. The only way I can think of I to do it 
> without monkey patching would be to make ajax requests to get the new 
> representation of the chosen object - substantially more awkward both for 
> the developer and the person installing the app.
>
> I appreciate some people will have used ForeignKeyRawIdWidget outside 
> admin and used a custom dismissRelatedLookupPopup function so ideally any 
> change would not break their code. This means that the function signature 
> of dismissRelatedLookupPopup should remain the same (unfortunately, as 
> this would be the most obvious and easiest place to include representation).
>
> My proposal would be for the string representation of the object to be 
> included somewhere in the popup - for example as an html attribute called 
> data-object-representation on the anchor with the onclick handler. If this 
> anchor was also given an id (say choose-object-X where X is the object's 
> pk) then it would be easily accessible to the dismissRelatedLookupPopup, 
> which could extract it and update the representation on the calling page. 
> The <strong> elem containing the representation might also benefit from 
> having a unique id as RelatedObjectLookups.js seems to be written so as 
> not to require jQuery.
>
> Hope that all makes sense. Naturally I'm prepared to write a patch for 
> this assuming it doesn't meet with disapproval.
>
> Thanks,
> Richard
>
> P.S. Hope I'm putting this in the right place, and I couldn't find 
> anything existing on the django issues list, and i got the impression that 
> this list was the place to start with such things.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to