MVC - Creating a Controller
§Prerequisites
§You have created an empty BSP application for this tutorial.
§Procedure
§Create a controller within your BSP application.
§To do this, choose Create ® Controller
§On the following dialog box, give the controller a name and add a short description.
§On the following screen, assign a class name to the controller. The class does not have to exist yet.
§You navigate to the Class Builder by double-clicking on the controller class. If the class does not already exist, the system asks you if you want to create it. Choose Yes so that you create a class with the specified name that is derived from CL_BSP_CONTROLLER2.
§Each controller class must be derived directly or indirectly from CL_BSP_CONTROLLER2.
§Choose the symbol to branch to the change mode in your class
§DO_REQUEST and choose symbol to overwrite the methods.
§Generate the required output. In this example, it is simple HTML:
§Activate your class and your BSP application.
§Before you can test the controller, in Transaction SICF you must also activate the new entry that was automatically created for your BSP application .
§In Transaction SICF, select the entry for your BSP application and choose Service/Virt.Host -> Activate.
§You can now test the new controller page that you have created.
§If you do not always want to use the write function to create the HTML page content, and you want to create it as pure HTML layout instead, then create a view that you can call from the controller.
§Procedure
§ 1. Begin as if you are creating a normal page with flow logic in your BSP application.
§To do this, choose Create ® Page.
§ In the following dialog box, enter a name and short description of the view and select View as the page type:
§Create the attributes for the
§ variable parts of the view.
§Create the following
§ attribute:
§Define the layout as usual:
§Activate the view.
§Finally, adjust the DO_REQUEST method to
§ the controller class.
§Here, the schema is always the same. First you create the view, then you set the attributes, and then you call the view. (For the time being you can ignore the warning concerning exception CX_STATIC_CHECK, or you can set a try-catch block around the calls)
§Activate your class and test your controller.
Calling a Controller
§Use
§You can call a controller from a page with flow logic, or from a view.
§Procedure
§Create a page within your BSP application. Ensure that you select Page with Flow Logic as the page type.
§In the Tag Browser, select BSP extension bsp and drag it to the second line of your BSP’s layout under the page directive.
§Now drag the <bsp:goto> directive of BSP extension bsp to the body of the HTML layout and add the URL parameter. The source now looks as follows:
§You can now activate and test the page.
MVC - Summary
§Model:
§Encapsulates business data and functionality
§Data source for visualization
§Single point for retrieving and updating data
§The logical structure of the data underlying the application
§View:
§Visualization of application data
§Views do not have event handlers
§Controller:
§Manages interaction between the client and the model and view.
§Handles user events
§Responsible for executing views directly
Interaction of MVC Components
§MVC is more flexible than standard BSP approach in that it separates the view code from the request-handling code. This allows views to be dynamically chosen and controlled from a central controller class
§Views are passive objects without events, this forces the separation of application and display logic stored in a model
§Controllers themselves are callable and can be reused in other applications
§Controllers and views can cascade downward to other views and controllers allowing for a more component based design rather than a monolithic one.
§Component approach leads easier manageability of the various aspects of the application
§As BSP applications get more complex, the utilization of MVC makes more sense
§As an example, imagine the following scenario: In the non MVC creation of a BSP application, you might use many similar looking pages that contain identical views of data in multiple locations in your application. If a general decision is made to suppress a particular field across the application, the developer would have to go into every page and modify the page to suppress that field.
§If MVC is used, a single view can be used on multiple pages to display the data. Suppressing the field is then a simple matter of changing a single view. The same is true of ADDING a field. The model is changed in one place to pull in the additional data, and a single view has to be changed to display the additional field.
No comments:
Post a Comment