-
Task
-
Resolution: Fixed
-
Major
-
5.2
-
None
-
-
Empty show more show less
-
Empty show more show less
Currently, the control migrators registered in a dialog migration task are inherited by class hierarchy.
For example, DialogMigrationTask define a bunch of migrators, and his sub class DamDialogmigrationTask add migrators.
A custom module may want to uses the migrators defined in Dam, but also the Category and Data one. This is currently not possible but necessary.
The solution is to use a registry of migrators defined at the module level, and to define a new DialogMigration task that uses those registry to build the available migrators list.
Task:
- Create a new ControlMigratorsRegistry.
- Singleton filled by the modules version handlers that defines custom controls and migrators
- Define a new DialogMigratortask that uses this registry (DialogMigrationRegisteryTask)
- Adapt the module version handlers that defines specific ControlMigrators
- Adapt the existing DialogMigrationTask in order to be backward compatible
- depends upon
-
MAGNOLIA-5543 Use Components to create new instance of ModuleVersionHandler in order to use injection
- Closed
- is depended upon by
-
MGNLCAT-120 Register ControlMigrators in the Categorization module version handler
- Closed
-
MGNLDAM-360 Register ControlMigrators in the DAM module version handler
- Closed
-
MGNLDATA-233 Register ControlMigrators in the Data module version handler
- Closed
-
MGNLFORM-216 Register ControlMigrators in the Form module version handler
- Closed
- mentioned in
-
Wiki Page Loading...