Page History
...
- No configuration in the tree is possible.
- Choose dialog actions are hard-coded and give no freedom in modifying the logic of choosing.
- Hacky and complex implementation of choose dialog for a content app is hidden behind a minimalistic ChooseDialogPresenter interface.
- By default, when a content app is asked to provide a choose dialog - it duplicates a workbench and img provider def.
- It uses WorkbenchChooseDialogPresenter and does all configuration in ContentApp class.
- Child classes (e.g. AssetsApp) don't have a direct access to the implementation - everything has to be casted and a lot of assumptions have to be made in order to introduce modification.
- Choose dialog had to be closed manually by the consumer.
What can be done?
- We can treat choose dialogs the same way we treat form dialogs.
- Configuration stored in registry.
- Contains configurable actions (e.g. ChooseDialogCallback actions).
- Configurable choose dialog UI-content.
- Most configs like actions, title and label can be shared between form and choose dialogs.
- The main difference - instead of configuring the whole form we only need one field, whose value would be used for selection.
- Workbench can be adapted to a CustomField fairly easy (at least without modifying the workbench itself).
- We set up a registry for choose dialogs analogous to the form dialog registry (they extend all the base classes).
- We do not use a ChoseDialogPresenterFactory anymore.
- In order to get a different choose dialog for an app a developer would have to implement a new factory and we don't want that.
- We inject a ChooseDialogPresenter instead and it builds the view based on provided definition.
- Choose dialogs can be now called by name (and/or by definition).
- Looks like we can now have several different choose dialogs for a single app.
- We can actually keep the old mechanism of creating a choose dialog as a fallback - in case absolutely no choose dialog is defined for an app at least try to construct it from the browser sub-app.
- Actual choose process happens by means newly introduced ChooseDialogCallbackActions - similar to those DialogCallbackActions that fire a callback.
- The only difference more or less is that besides an action name we pass a chosen value into the callback (maybe there should be some kind of a callback context object so it would look prettier).
- Additional choose logic can be added effortlessly to these action.
- To close or not to close dialog.
- To accept selection or not to accept selection (had a request for forbidding selection nodes without children just yesterday, the solution involved creation of custom ContentPresenters).
- To fire additional notifications if needed.
Overview
Content Tools