
To open the cheat sheet, refer to step 4 in the topic Migrating Web Dynpro Development Components .
Preparing your Web Dynpro Components for Migration
Move Views
The new programming model for Web Dynpro components requires that all views of the component are physically stored within the same package as the component itself. The views for which the packages have to change are listed in this step of migration.
Move Custom Controller
The new programming model for Web Dynpro components requires that all custom controllers of the component are physically stored within the same package as the component. The custom controllers for which the packages have to change are listed in this step of migration.
Move Windows
The new programming model for Web Dynpro components requires that all windows of the component are physically stored within the same package as the component itself. The windows for which the packages have to change are listed in this step of migration.
Conflicting Windows Name
The new programming model for Web Dynpro components requires that all windows of the component have a window controller. These controllers will be created during migration. On the other hand, there must not be two controllers with the same name within one Web Dynpro component. The step lists windows for which this constraint is violated. The window or the object with the conflicting controller has to be renamed.
Keep in mind that renaming an object that is visible from the outside might break the build of other components that use the component being migrated.
Component Package Check
The new programming model for Web Dynpro components requires that you reserve a package solely for a component and its sub-objects. The term "sub-objects" refers to windows, views, and the local component interface controller. This step lists the objects found within the package of the component that might conflict with this requirement. Either the component has to be moved into another package or the conflicting objects need to be refactored.
Check Native Interface Inheritance
During the migration of the component it is necessary to let the component local interface extend all implemented interfaces and to enable 'native inheritance' for the component local interface. This needs to be done in order to keep the programming interface compatible with the version before the migration. On the other hand, 'native inheritance' must not be enabled if one of the inherited interfaces has a version that is too old (in other words, was created with SAP NetWeaver Developer Studio 04 or 04s).
The standalone component interfaces listed below bear such a conflict. These conflicts can be solved in one of two ways: either migrate the inherited component interface to the newer version (using the context menu function Migrate for the interface ), or create a new standalone interface, let this interface extend the problematic one and implement the new interface.
Migrating the component interface will also slightly change the runtime behavior of the interface, which might have consequences for any components that use the component containing the migrated interface. It is no longer possible to cast from the Java interface corresponding to a Web Dynpro component interface to another one, as there are separate runtime representations for each implemented Web Dynpro component interface.
Implement Interface Controller
Within the new programming model for Web Dynpro components, the component controller is required. This component controller is used to implement the following:
In order to do so, the declaration of all objects within these interface controllers must be replicated into the component controller. This cheat sheet thus helps you to copy all the relevant objects into the component controller. After that, only the relevant coding contained within the component's local interface controller needs to be moved to the component controller. Moving the coding may require that it is adapted. Use Check implementation relation to find out which objects defined in the interface controller are not implemented within the component controller and if there are any conflicts. You can then use Implement interface controller to automatically copy all relevant objects from the local interface controller to the component controller in order to fulfill the necessary implementation relation.
Hint: If the context of the interface controller contains nodes with context mappings to the component controller, this will create implementation errors such as 'The type of the attribute in the interface definition is missing'. To solve this, simply delete the mappings from the context nodes in the interface controller to the component controller.
Transfer User Coding Areas
This step lists the user coding sections of the local component interface controller which may contain Java coding that needs to be transferred to the component controller. These user coding areas have to be copied manually to the appropriate sections of the component controller.
Replace/Delete References
The new programming model for Web Dynpro components requires that the implementation of all interface coding and the storage of data is contained within the component controller instead of the interface controller. This means that all references to methods and data previously held in the interface controller must be replaced with references to the corresponding methods and data that have now been transferred to the component controller.
After you have performed this step, the component will not run any more. If you redefined some of the context elements during the previous step, the list might be out-of-date. If this is the case, restart the cheat sheet activity.
Delete Implementation Coding from Interface Controller
In the new programming model for Web Dynpro components, there is no way to implement any coding in the component's local interface controller. The coding that was stored there in the old programming model must first be transferred to the component controller (as described in the previous steps). Now the redundant coding in the interface controller can be deleted. Click the item in the cheat sheet to perform this automatically. Make sure you have transferred all necessary coding to the component controller before proceeding!
After you have performed this step, the component will not run any more.
Delete Implementation Metamodel Objects
Once the coding stored in the component's local interface controller has been deleted all that may remain are some metamodel objects such as controller usages, supply functions and calculated attribute provider methods. These objects will now be deleted by performing this step. Make sure that all these objects have been transferred to the component controller before proceeding!
After you have performed, this step the component will not run any more.
Start Migration
If all the previous steps are executed successfully the component is ready for migration. You are now ready to execute the step that actually migrates the component.
Any coding from the Interface View Controller is not copied to the Window Controller. This coding must be transferred manually.