Concept - Legacy admininterface

Problem

We want to drop the old ui modules, namely admininterface, gui and fckeditor. However, those modules are used almost everywhere, and dropping them without first porting the existing modules' UIs to 5.0 would mean, in many cases, a severe loss of functionality (think of data module which is used by several other modules). Given our time constraints (release due on 20th June 2013) porting even some of them is not a viable option. So here comes the compromise.

Proposal

Create an admininterface-legacy (for want of a better name) module which holds all the old ui modules classes. This would guarantee an almost complete backward compatibility of existing modules with 5.0.

Classes in this module would

• keep their original packages
• be all deprecated and encourage users (and ourselves!) to port existing modules to 5.0 apps
• provide an update Task to easily wrap old Uis as 5.0 apps

Almost complete backward compatibility

To avoid confusion with the commands now provided by core, activation and dam, the legacy module will not contain any commands. Existing modules using commands provided by the old adminInterface will need to rewrite them by using their new counterparts. In most cases this amounts to changing a couple of imports, given that the command names have been kept, and/or update bootstrap files.

In practice

To make an existing module UI work in 5.0, one will need to

1. replace references to old ui modules in pom.xml with the info.magnolia:magnolia-module-legacy-admininterface:5.0 artifact
2. replace references to old ui modules in own module descriptor (the one under META-INF/some-module, not to be confused with pom.xm) with the adminInterface 5.0 version 
   
   1. e.g. suppose you have a module descriptor declaring a dependency on gui or fck-editor 4.5/*. What you have to do is replacing those dependencies with adminInterface 5.0/* (the Magnolia module name for legacy-admininterface). If you instead have a module descriptor already depending, e.g. on adminInterface 4.5/* then you only need to replace its version with 5.0/*
3. change imports in the existing custom commands, e.g. replace info.magnolia.module.admininterface.commands.BaseRepositoryCommand with info.magnolia.commands.impl.BaseRepositoryCommand
4. update bootstrap files referring to old commands with their new counterpart, e.g. replace info.magnolia.module.admininterface.commands.VersionCommand with info.magnolia.commands.impl.VersionCommand 

5. add an update Task to wrap the old UI (basically either a page or a tree) as a 5.0 App, something along these lines

   WrapAs5ohApp

   public class MyFancyModuleVersionHandler extends DefaultModuleVersionHandler {
       public MyFancyModuleVersionHandler() {
           register(DeltaBuilder
                   .update("4.5", "5.0")
                   .addTask(new WrapLegacyModuleAsMagnoliaAppTask("myapp", "My app label", "someAppGroup", "an-icon", "pageUrlOrTreeName")));
       }
   ...
   }

   This would spare developers the tedious job of creating a proper app config in ui-admincentral. 

List of 5.0 compatible modules

As a general rule, 5.0 compatible versions of existing modules are the next major version after their 4.5 compatible versions. I.e. the resources module for 4.5 is 1.5.x, therefore the 5.0 version is 2.0.

One notable exception is STK whose 4.5 version is 2.0.x whereas the version to be used with 5.0 is 2.5. Another exception is forum which passes from 1.3.x to 3.0, due to the fact a 2.0 branch already existed for it.

Jira issue linked to this task

Unable to locate Jira server for this macro. It may be due to Application Link configuration.