Page History
...
- We can treat choose dialogs the same way we treat form dialogs.
- UPDATED: Content app
AppDescriptor
will contain definition of a choose dialog.- AppDescriptor will be extended for the case of content app.
- AppContext has to expose AppDescriptor in order to let apps access it (the method was lost a long time ago during AppInstanceController introduction refactoring).
- Choose dialog configuration can now reside on an app level.
We extract the generic registry for base dialogs out of the form dialog registry and create choose dialog registry on its basis.Definition managers and providers can be created the same way.
- 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.
- UPDATE: Customizable presenters.
- Both form and choose dialog presenters can be configured so that we could provide more complex dialogs.
- There could be a potential benefit in configuring even dialog actions - instead of buttons we could provide combo-boxes and e.g. uploads.
- UPDATED: Content app
Overview
Content Tools