Enable / disable the open-modal button on reaching the limit, as we do for InlinePanel's standard add button; and when handling the response from the modal, stop adding new items when max_num is reached
Extend the existing 'chosen' view so that it returns a single-item list when the URL parameter `multiple` is passed, and add a 'chosen_multiple' view that accepts multiple `id` URL parameters and returns the corresponding results as a list.
Change the ADD button's ID suffix to OPEN_MODAL (to bypass the standard panel insertion) and pass chooserFieldName to the JS constructor (currently ignored).
We keep data-chooser-url in the HTML output, and use it as a fallback in the JS - for backwards compatibility with existing BaseChooser subclasses that don't pass an options dict (such as AdminTaskChooser, which overrides render_js_init)
At this point we've been turning the 'opts' dict from a private API specific to PageChooser, that more or less transparently passes options on to the modal as URL query parameters, into a convention shared across all chooser widgets where the question of "will this option become a URL parameter" is an internal implementation detail. Since this is notionally a bundle of JS variables rather than a bundle of URL params, we should take this opportunity to consistently adopt camel case, before this pattern becomes widespread in third-party code and ends up as a mishmash of camel-case and snake-case.
The old signature is still accepted for backwards compatibility.
This then matches the signature of the other chooser widget JS classes, allowing PageChooserFactory to extend the generic ChooserFactory.
This will allow us to refactor it, including adding class-level references to window.PageChooser and window.PageChooserModal as necessary, without dealing with the possibility of telepath/widgets.js being imported before the includes that define those.
This is necessary (according to the logic for adding Django form media objects together) whenever the JS adapter definition depends on anything defined in the widget JS - e.g. if foo-chooser.js defines `window.FooChooser`, and foo-chooser-telepath.js references that in the definition of FooChooserAdapter, then the only way to guarantee the correct ordering is with an explicit `['foo-chooser.js', 'foo-chooser-telepath.js']` media definition - adding two media objects does not guarantee this ordering.
This matches the implementation in components/ChooserWidget. This change breaks the tests that pass a jQuery collection object rather than a DOM element, but that was never valid in the first place as per https://docs.wagtail.org/en/stable/reference/streamfield/widget_api.html - fix the tests accordingly.
Previously, anything invoking the chooser modal needed to make its own call to ModalWorkflow, which meant it needed to import the corresponding 'onloadHandlers' dict, know the appropriate chosen response identifier to listen to, and know how to modify the chooser URL to pass parameters (if applicable). This would mean a lot of duplicated logic if there were multiple places where the modal is invoked.
Here we introduce a ChooserModal base class which encapsulates those details - a caller just needs to instantiate it with the base URL, and call `open` on it to open the modal (passing an options dict and a response callback).
- Revise 'redirect' from a string to a 'continue' boolean that defaults to false
- Use 'continue=true' for cases where we do not want to create a next param on submit that takes the user back to the current page
- Fixes #9815
