Hi Richard, Thanks for your rationale. Sounds like a good feature to me.
Probably the best way to proceed is to make a ticket at: https://code.djangoproject.com/newticket , attach a patch or pull request and then we go forward. Best regards, Wim On Wednesday, 12 June 2013 19:33:31 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.
