View source for Riena/Preparation

Riena was designed for enterprise applications with many views. To handle all these views Riena has some special concepts: [[Riena/Navigation | Navigation Model]], Shared Views, etc..

To avoid that the start of the application is to slow and needs a lot of resources, the controller and the view of a sub-module is only created when a sub-module is activated.

In some cases this behavior have some disadvantages, because the controller of the sub-module and according model are not bound, yet. Without binding error and mandatory markers can't be displayed in the navigation tree. If you need these information, you can define that a sub-module is created, when the navigation model is created. Riena supports this feature since the version 2.0, it is called "preparation".

The Riena application developer can enforce the preparation of sub-modules in three different ways:
* The element submodule of the extension point "org.eclipse.riena.navigation.assemblies" has an additional attribute: requiresPreparation.
* IWorkareaDefinition has the additional property requiresPreparation.
* NavigationArgument, which is (for example) used in the method navigate of the class INavigationNode, has the additional property prepareAll.
The creation of a sub-module controller wasn't possible without the creation of the sub-module view. Because the method configureRidgets of the controller expects that the Ridgets are already injected and Ridget injection without a view wasn't possible.

This prerequisite is not necessary with Riena 4.0. The preparation of a sub-module only creates the controller and bound it with the model. The according view will be created, when the sub-module is activated. This allows the developer to find a well-balanced compromise between user support (e.g. markers) and performance/consumption of resources.

That a controller can be created correctly without a view, the developer must consider one thing: The implementation of the sub-module controller should avoid the method getRidget(String); instead the method getRidget(Class,String) should be used. It is necessary to mention the class that the method should return, because now it isn't possible to identify the correct Ridget class by the widget.