If we were happy with that particular implementation, then I'd prefer
adding it as an official subclass thats importable for users rather than
just dumping the code to the docs. But I guess the issue is a slippery
slope - how many subclasses do we add for various ModelAdmin use cases.
It's definitely an issue that bites many people, and I'd like to see some
way forward.
On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>
> Ok, sorry for the Fake News, seems like it's not so complicated to make
> one ModelAdmin parent class that provides this behavior. Here's a working
> example:
>
>
> from django.contrib import admin
>
> from django.contrib.admin import widgets
>
>
> class RawFieldModelAdmin(admin.ModelAdmin):
> def formfield_for_foreignkey(self, db_field, request, **kwargs):
> db = kwargs.get('using')
> if 'widget' not in kwargs:
> if db_field.name not in (self.get_autocomplete_fields(request
> ), self.radio_fields):
> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(db_field.
> remote_field, self.admin_site, using=db)
>
>
> return super().formfield_for_foreignkey(db_field, request, **
> kwargs)
>
> Do you folks think we should add this to the docs? I still think that
> having a one-off setting for the "default foreign key" widget would be
> valuable, at least for me as a user.
>
> What do you think?
>
> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto wrote:
>>
>> I think the proposed solution of "you can just extend/subclass
>> ModelAdmin" doesn't work, because the fields on different models can have
>> different names. I can't just write one global ModelAdmin and then use it
>> for all my models, because they'll have different names for their fields.
>> Or if it works, it'll need A LOT of introspection (to dynamically check
>> which fields are FKs and making them part of raw_id_fields).
>>
>> Maybe I'm wrong and I'm missing the point, do you folks have an
>> implementation of that ModelAdmin superclass to show?
>>
>> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote:
>>>
>>>
>>>
>>> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>>>
>>>> One problem with any of the alternatives (besides making it readonly by
>>>> default) is that it requires the other model to be registered in the admin
>>>>
>>>
>>> Off-hand I don't follow you here. Can you explain.
>>>
>>>
>>>
>>>> I hope there's _something_ we can do to somehow improve the situation.
>>>> Maybe we could at least improve the examples in the documentation? Maybe
>>>> give an example in the docs of a ModelAdmin subclass that defaults to
>>>> using
>>>> raw_id?
>>>>
>>>
>>> An example definitely.
>>>
>>> Maybe we could add an attribute to ModelAdmin with a number: More than
>>> this use raw_id — but what would that look like?
>>> (Easy subclass rather than a setting...)
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ec47fd5a-5c34-47ad-805d-d2036d430aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
