-
Story
-
Resolution: Fixed
-
Critical
-
None
-
-
Empty show more show less
-
RC 1, 5.1 Beta1- Frontend, 5.1 - RC1
WAS: "Review, Document and Improve Choose Dialog"
The ChooseDialog structure and related code has grown over time naturally. In order to make this structure, it's purpose and use easy to understand to other developers writing their own apps we need to
- review naming of the classes
- review javadoc
- document the structure and it's use in architecture documents & diagrams
- provide parallels or examples of where how this structure is used and what is intended use
- restructure the code to minimize duplication and simplify creation of such dialogs
Idea: Instead of getting the app from the appController and then creating the presenter and opening it manually, this should be abstracted by the appController: appController.openChooseDialog("app name")
Currently there is only one chooseDialog per app. Better per subApp?
- is related to
-
MGNLUI-1992 Develop field adapter for a workbench.
- Closed
-
MGNLUI-1993 Remove choose-dialog related hacks out of workbench definition.
- Closed
-
MGNLUI-1996 Streamline dialog definitions, packages and choose dialog related actions.
- Closed
-
MGNLUI-1997 Create registry and definition manager for choose dialogs. Extract base parts corresponding form dialog classes.
- Closed
-
MGNLUI-1998 Improve ChooseDialogPresenter and ChooseDialogView. Get rid of ChooseDialogPresenterFactory.
- Closed
-
MGNLUI-2001 Adapt changes made to dialog API to the use-cases.
- Closed
-
MGNLUI-2006 Design special app descriptor for content apps. Keep choose dialog definition there instead of a special registry.
- Closed
-
MGNLUI-2020 Provide default choose dialog configuration for content apps.
- Closed
-
MGNLUI-2027 Improve signature of openChooseDialog method in AppController and App.
- Closed
-
MGNLUI-2052 Create migration tasks necessary for new choose dialog concept, update bootstrap files.
- Closed
-
MGNLUI-2071 Make sure new dialog concept works with i18n controls.
- Closed