GSoC 2022: Create and select related content

[allcaps]

CANCELED, #8157 (comment)

Discussion about Create and select related content a Google Summer of Code project.

Django

Django has a way to select related content AND create, update and delete related content without leaving the current form. It does this by opening new windows.

See this video illustrating the differences between Django and Wagtail related objects.

A select field in Django has a create (plus), edit (pencil) and delete (red cross). It opens a new window that allows performing CRUD actions.

Also, Django raw id field has a search loop. It opens a chooser in a new window. It re-uses the model admin list view. Advantages are:

• Enables custom list fields, search and filter.
• Pagination.
• With a lot of content, you don't have to render all select options in the current form. Boosting performance.

Wagtail

Creating related content in Wagtail involves tedious and annoying steps:

You need to navigate away from the current form (losing your work).

• Create the related object.
• Go back to the initial form and recreate all content.
• Forms with many fields have the chance of losing a lot of work. There is also a chance that the user is required to repeat steps 1-3 a couple of times. There might be multiple required related object fields.

The current Wagtail snippet chooser opens a modal. The modal:

• Does support content selection
• Does not support CRUD actions
• Does not re-use the list view (like Django does). Customisation of list fields, search, and filter is hard/impossible.

Wagtail has no raw_id_fields.

Expected outcomes

This GSOC project is about related object selection and CRUD in Wagtail:

• Create a chooser window that re-uses the ModelAdmin list view.
• Create related object CRUD views. They open in a new window.
• Respect user permissions on the related objects.
• Make nested related object CRUD (multiple windows) possible.
• Introduce RAW id field.

[jacobtoppm]

I have a few concerns.

1. Currently snippets are used for choosing, modeladmin for an alternative editing interface. If we're reusing something like the modeladmin listing view for choosing - which snippets mostly won't have, so we're effectively encouraging people to use modeladmin for a better experience - we should do this only as part of something that brings modeladmin and snippets closer together. For instance, rather than using modeladmin filters etc as-is, I feel like we should rewrite them to use the filters (Django-filter based) used in the rest of the Wagtail admin (currently they reuse Django admin code, which is a little awkward to use at times).
2. Are we sure we want to go the raw id field + separate window approach, rather than improving the existing snippet chooser modal to add create (or even CRUD) functionality (+ solving the nested modals issue)? This feels a bit like we might be encouraging people to use a worse UI for slightly better functionality.

Copy/Pasted from later in slack discussion:

I think we might be talking slightly at cross purposes, sorry! I agree in many cases, ModelAdmin has better features (it's also missing some - translation, for example, as I recall). I'd very much like to see snippets and modeladmin combined into one feature that has all the features from both. If we choose to build upon ModelAdmin, we need to get rid of some of the clunky code that comes from trying to reuse internal bits of Django's ModelAdmin in ways it wasn't intended, and ideally IMO make its code have more in common with editing page models - for example, my suggestion of migrating its filters to use django-filter instead, as the rest of the admin does. If we choose to build upon snippets, we need to add those missing features.

My concern is that we continue to have two separate, diverging implementations of basically the same concept, each supporting slightly different features - it's confusing both for implementors and Wagtail developers.

[phildexter]

This is an excellent problem to think about solving, and very well described. Thanks @allcaps !

I think I agree with your thoughts @jacobtoppm - let's go for one standard and make it great. At the moment I think there is a view that we'd try and improve snippets, but perhaps this is something to discuss more in the core team meeting.

In terms of the specifics of the UX for "creating as part of choosing" - I think we should be designing this as part of the new page editor work that is ongoing, so that it fits in with the other choosers and can be built on top of the generic chooser work @gasman has been doing. I've just reviewed our designs and am surprised that I can't see a design for it, which I think has just been missed. So we'll try and do some design on this next week and come back here for more thoughts and feedback, if that works?

In terms of this being a good candidate for a GSoC project I don't think I have a good enough understanding to comment, but would welcome @thibaudcolas and/or @gasman to give their view on it.

[allcaps]

This post has a preview of new choosers by @benenright
#7739 (comment)

[allcaps]

I'm a big fan of the 'list view as chooser list' concept. It makes configuring a chooser super easy. But I also agree with the feedback that forcing modelAdmin usage is a bad idea. But the same can be said for the snippets menu.

We agree on the problem: two separate diverging implementations for CRUD actions. Merging snippets and model admin will solve the issue.

An alternative is to create a chooser register to define choosers. The downside is that this will give us yet another series of views. These views will duplicate the logic from ModelAdmin and Snippets menu yet again. :/

Opening a new window for a chooser instead of a modal is a simple way to make editing infinite nested objects possible.
A new window is also resizable. Windows can take the full-screen to focus on what you are doing. It is crucial when creating and updating. Maybe a modal can achieve the same? I'm not sure. Advice is welcome.

[jacobtoppm]

I'm not too opinionated on window vs modal - this is one where I think we need some design feedback. I do think needing the raw id field feels like a bit of a worse user experience (saying a snippet is snippet "2" is a lot less meaningful than seeing an actual representation).

I wonder if it's worth us taking a step back, and focusing a project around actually merging snippets and modeladmin as first steps before we bring this in. (I'm definitely not saying we need to keep things like the snippets menu - that could be made configurable - or necessarily even build on top of the current snippets codebase, but I really don't like the idea of having parallel choose views, I'd rather push for one stronger implementation) Say for example we:

• Focus first on making snippet listing customisable, just like modeladmin
• Add filters
• Add a version of the snippet chooser which reuses this listing view, and allows creation of snippets alongside selection

[gasman]

My hope is that (some version of) https://github.com/wagtail/wagtail-generic-chooser will become the new standard chooser implementation, and will be suitably customisable to allow filterable listings and integrated 'create' forms.

See wagtail/wagtail-generic-chooser#44 for a roadmap / outline of what needs to change to make the wagtail-generic-chooser code usable in Wagtail. There's also a few bits of ongoing work in the Wagtail repo such as #7780 (which now needs some reworking following the locale-related changes in #7837). My current work on edit handler refactoring probably feeds into this too: currently all of the 'create' forms within modals are plain Django forms, whereas snippet creation will presumably need an edit-handler-based one, so a generic implementation will need to handle both types - and hopefully the new edit handler code is more aligned with Django forms than it was before.

So, quite a lot of threads to tie together - not sure if that makes it less suitable for a GSoC project.

[thibaudcolas]

Just a note for people looking this that we’ve decided to cancel this project, because it’s tied to too many other bits of work.