> > 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 stand corrected. raw_id_fields doesn't actually require the other model to be registered. On Fri, Jan 18, 2019 at 7:25 AM Harro <hvdkl...@gmail.com> wrote: > The problem is that you can't just use it everywhere, like mentioned > earlier it only works if the other side of the relation is also available > in the admin (which might not be the case, or only for some of the fields.) > > I would say add it to the good old djangosnippets > <https://djangosnippets.org/> website. > > But that's just my 2 cents. > > On Friday, 18 January 2019 12:50:52 UTC+1, Josh Smeaton wrote: >> >> 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/f888916c-78b9-4a06-aa83-c880a114d034%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f888916c-78b9-4a06-aa83-c880a114d034%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFO84S59%3DvkNJtk%2BFOxK_Gy9-TQBbAwf_L5xuhuUhvJ%3DS4NQ1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
