Generic ModelChooserBlock for StreamField

I’d like to propose a ForeignBlock or similar using models.ForeignKey as it’s base for allowing integrations with other model clusters/models. It would most likely need to extend blocks.ChooserBlock and shouldn’t be too difficult.

[m1kola]

Currently there are two ways to manage non-Page models in Wagtail:

• Using Snippets
• Using Model Admin (contrib module)

When you register your model as a snippet it allows you to edit objects through the Admin -> Snippets -> Your snippet name menu and use nice chooser UI in the editing interface.

However there are few cases when this behaviour doesn’t work really well:

• When you need fairly complex admin UI (with filters, for example) and have the chooser UI. In this case, most likely you would decide to use Model Admin, but Model Admin doesn’t allow you to use the chooser UI. There is a workaround: you can register your model as a snippet alongside with Model Admin UI. As a result you will have two places to edit snippet: one in the Admin -> Snippets -> Your snippet name and one in the Model Admin UI which is confusing. Generic model chooser should solve this issue.
• When you need to have the chooser UI for snippets that do not need editing (data imported from some API, for example).

Taking into account the last point, it seems to me that the generic model chooser must not rely on Model Admin. I think, it should be something like the existing register_snippet but without exposing editing UI.

[ababic]

I think the blocker to having a ModelAdmin-based chooser has been: ModelAdmin classes/instances know about the model they represent, but there’s no easy way to access a ModelAdmin class/instance from a model. Without moving to a ‘django-like’ registration method, where the relationships between models and ModelAdmin classes are stored in a central/reference-able place, I don’t see how we can circumvent this. But that has a tonne of other implications that need thinking through. That’s maybe a discussion for the developers board though, rather than here.