In Web dynpro component, there are 6 types of controllers:
- Component controller
- View controller
- Custom controller
- Configuration controller
- Interface controller
- Window controller
Each Web Dynpro component contains exactly one component controller. This controller is automatically created during the component creation and contains a context, events, and methods. Unlike a view controller, the component controller is visible for all views in a component. This means, the controllers of different component views can access context elements or methods of the component controller. For this purpose, the component controller usage is automatically created for every view controller.
This makes the component controller a central location for data exchange between different views of one component. The Web Dynpro framework provides the mechanism of context mapping which is a declarative tool to easily perform this data exchange.
In addition, the component controller allows Cross-View Method Calls For example, it might be useful to add the call of a function module to a method of the component controller if the function module is to be used by methods of different views. You can then access the methods of the component controller in the controllers of the various views. This enables you to structure Web Dynpro components in a better way and to reuse frequently used program steps.
Context Mapping
Data stored in the context of the component controller can be used within a view if you link the node of the view context to the corresponding context node of the component controller. This procedure is called “defining a mapping”. For further information, refer to the chapter Data Binding and Mapping in the architecture manual for Web Dynpro.
The following graphic illustrates the principle of the procedure:
The context of View 1 of the example in the graphic contains two nodes below the root node:
● The node Node 1 is mapped to the node of component controller context of the same name. This means that the structure within the node matches the structure within the node of the component controller or the structure is contained in it. At any time, the values of all attributes contained in Node 1 are identical to the corresponding attributes of the component controller. If the attribute value of the view context changes at run-time, - for example, due to a user input - , the change is directly passed to the component controller.
● The node Local Node View 1, however, is exclusively known within the view controller, and only the methods of the View 1 have access to the values of the node attributes.
2. View Controllers
Layout and flow logic are very closely connected to each other in a view. As part of a view, the view controller – unlike other controllers – is therefore not edited in the Controller Editor. Instead, the necessary tools have been integrated into theView Editor, which can be used to edit the view as a whole.
Just like the component controller, the view controller contains data and functions. Furthermore, the view controller also has an IF_<Controllername> interface, which means that these data and functions are visible within the same view only.
The lifetime of the controller element of a view is restricted to the lifetime of the view. To create simple Web Dynpro applications, it is sufficient if you maintain the component controller and the view controller of a view. The two controllers described below are optional and help you to structure complicated components and applications, thereby increasing their reusability.
A custom controller is a special type of controller of a WD application, which you create explicitly if required. Like all other controller types, the custom controller contains a context class, which is automatically generated when you define the custom controller. The custom controller is also the responsible part of the WD application that implements the event handlers and validators that react to actions.
The properties and use of the custom controller that can be added optionally correspond exactly to those of the component controller. This means that it is visible to all elements of the component and the lifetime of the elements is the lifetime of the component. The custom controller gives you the option of structuring functions and data within a component. It makes sense to create and maintain a custom controller if a certain subset of views of a component should be equipped with a special function or with a special set of data.
It is recommended to go with an example of custom controller:
http://saptechnical.com/Tutorials/WebDynproABAP/Controller/Index.htm4. Configuration Controller
Configuration controller in turns a custom controller.
What is the use of Configuration controller?
It is necessary if the corresponding component implements special configuration and personalization.
Eg: Setting the visibility of a view element dynamically for different users
Instead of writing code to set visibility we can maintain the visibility in configuration. Each user group can have their own visibility settings through configuration.
All attributes that should be accessible via configuration have to be defined in the context of the configuration controller.
Limitations of Configuration controller:
– Only one configuration controller may exist in any component.
– Any controller can access the configuration controller, but configuration controller cannot access any other controller.
– Life time of this controller is as long as the component lives.
Creation of configuration controller:
Step1: Create a WD component
Step2: Create a Custom controller by right clicking on component
Step3: Now you can see the extra folder in component hierarchy for custom controller.
Step4: Change the custom controller to configuration controller by right clicking on the custom controller
Step5: Now you can see that, name has been changed to configuration controller.
Like component controller, we can create context attributes in custom controller.
Nodes which we created in configuration controller will be available during configuration.
Now create a node for visibility with type WDY_BOOLEAN.
Step6: Create a context node in view controller and place the UI elements in the view
Step7: Unlike component controller, configuration controller context will not be available to view controller. To make it available, create component usage in view controller properties.
Step8: Map the context from configuration controller to view controller.
Step9: We want to set the visibility through configuration to material number UI element.
So bind the visibility of material number with visibility node.
Step10: Create WD application
Right click on application and click on create/change configuration
Step11: One browser window will open to create application configuration.
Enter the configuration name and click on create
Step12: Enter the package name and click on OK
Step13: We have created now application configuration, Next screen prompt you to create Component configuration.
Enter the configuration name and hit enter. After hitting enter ‘Go to Component Configuration’ button will be enabled.
– Step14: Click on ‘Go to Component Configuration’ button
– Step15:In the next screen enter the configuration name and click on create and save it into one package
Step16: Node attributes which we created in Configuration controller will be available in Component configuration.
Step17: Now check the visibility check box to make the input field visible and Click on Save
Step18: Before testing the configuration make sure that, all configurations (Both application and component configurations) has been saved.
Now expand the application, there you can see the application configuration which we have created.
Assign the application name to the application parameter WDCONFIGURATIONID
Step 19: Test the application
Step 20: Now change the configuration to make the material number UI element invisible.
Double click on configuration. Click on start configurator.
Step 21: Click on Change
Step22:Click on the button ‘Go to Component configuration’.
Uncheck the visibility attribute and click on Save.
Step 23: Test the Application.
Conclusion: Each application can have N number of configurations. So each user group can set their visibility according to their requirement without touching the code.
References:
http://help.sap.com/saphelp_nw70/helpdata/EN/b9/b82c4142aef623e10000000a155106/content.htm
1
No comments:
Post a Comment