Introduction : Multiple UI technologies follow the MVC design pattern including SAP WebDynpro Java, JSF etc and now SAP UI5. The blog describes the MVC design pattern. The content is compiled from multiple SAP sources but put in a single reorganised view to enhance understanding and highlight key information.
Target Audience : Consultants who wish to have a high level understanding to MVC towards SAP UI5 development.
Problem : multiple types of views (JS, JSON, XML, HTML) and new ways to expose services (OData, JSON, XML, Resource Models) make it a tough task to understand MVC in the perspective of SAPUI5. The SAP documentation is spread out across multiple sources.
Solution : This blog attempts to compile data from multiple sources and put it in a simple, structured way so that information read persists in memory.
Outcome : At the end of the blog you will have a fair understanding of MVC in the context of SAP UI5.
Date Created : 15 Mar 2016
Note : This blog is a living document, I will keep on enhancing it with more, better structured information and formatted code with every iteration. So next time you come back to the blog it will better than before.
This can be slightly expanded to accommodate the Smart Controls and Annotations as well.
Model
A model in the Model View Controller concept holds the data and provides methods to retrieve the data from the database and to set and update data. A model object is a container for the data upon which your application operates. The business data within a model can be defined using various formats:
- JavaScript Object Notation (JSON)
- Extensible Markup Language (XML)
- Resource Model
- OData
| Server Side Models | Client Side Models |
|---|---|
|
|
|
|
| The dataset is only available on the server and the client only knows the currently visible rows and fields. Only loads the data requested by the user interface from the server. | Model data is loaded completely and is available on the client. |
| This also means that sorting and filtering on the client is not possible. Any changes in data binding or list operations require a new request to the server. | Operations such as sorting and filtering are executed on the client without further server requests |
|
|
| JSON Model is much compact in comparison with XML model. |
You can not only define one model for your applications, but define different areas in your application with different models and assign single controls to a model. You can also define nested models, for example, a JSON model defined for the application and an OData model for a table control contained in the application.
A web application should support several data sources, such as JSON, XML, Atom, or OData. However, the way in which data binding is defined and implemented within the UI controls should be independent of the respective data source. It is also possible to create a custom model implementation for data sources that are not yet covered by the framework or are domain-specific.
View
The view in the Model View Controller concept is responsible for defining and rendering the UI. SAPUI5 supports predefined view types.
Although XML and JSON notation has been introduced for SAPUI5 UI controls, the Model View Controller concept is also supported to facilitate traditional programmatic UI constructions.
The following predefined view types are available:
| Types of Views | Examples |
|---|---|
| <mvc:View controllerName="sap.hcm.Address" xmlns="sap.ui.commons" xmlns:mvc="sap.ui.core.mvc"> <Panel> <Image src="http://www.sap.com/global/ui/images/global/sap-logo.png"/> <Button text="Press Me!"/> </Panel> </mvc:View> |
| { "Type":"sap.ui.core.mvc.JSONView", "controllerName":"sap.hcm.Address", "content": [{ "Type":"sap.ui.commons.Image", "id":"MyImage", "src":"http://www.sap.com/global/ui/images/global/sap-logo.png" }, { "Type":"sap.ui.commons.Button", "id":"MyButton", "text":"Press Me" }] } |
| sap.ui.jsview("sap.hcm.Address", { // this View file is called Address.view.js getControllerName: function() { return "sap.hcm.Address"; // the Controller lives in Address.controller.js }, createContent: function(oController) { var oButton = new sap.ui.commons.Button({text:"Hello JS View"}); oButton.attachPress(oController.handleButtonClicked); return oButton; } }); |
| <template data-controller-name="example.mvc.test"> Hello <h1>Title</h1> <div>Embedded HTML</div> <div class="test test2 test3" data-sap-ui-type="sap.ui.commons.Panel" id="myPanel"> <div class="test test2 test3" data-sap-ui-type="sap.ui.commons.Button" id="Button1" data-text="Hello World" data-press="doIt"></div> <div data-sap-ui-type="sap.ui.commons.Button" id="Button2" data-text="Hello"></div> <div data-sap-ui-type="sap.ui.core.mvc.HTMLView" id="MyHTMLView" data-view-name="example.mvc.test2"></div> <div data-sap-ui-type="sap.ui.core.mvc.JSView" id="MyJSView" data-view-name="example.mvc.test2"></div> <div data-sap-ui-type="sap.ui.core.mvc.JSONView" id="MyJSONView" data-view-name="example.mvc.test2"></div> <div data-sap-ui-type="sap.ui.core.mvc.XMLView" id="MyXMLView" data-view-name="example.mvc.test2"></div> </div> </template> |
View types are offered for selection as view options in the application creation wizard. If you use SAPUI5application development tools, you can also plug in other view types. For defining other or custom view types, you extend the base class
sap.ui.core.mvc.View.
Controller
SAPUI5 uses the controller to separate the view logic from the model logic. The methods used for controlling the data flow are implemented in the controller.
You define a simple controller without functions as follows:
sap.ui.controller("sap.hcm.Address", {
// controller logic goes here
});
The string in quotes specifies the controller name. The controller file is then named Address.controller.js.
Note: The suffix .controller.js is mandatory for controllers.
Lifecycle Hooks
SAPUI5 provides predefined lifecycle hooks for implementation. You can add event handlers or other functions to the controller and the controller can fire events, for which other controllers or entities can register.
SAPUI5 provides the following lifecycle hooks:
| Lifecycle Hooks | Description |
|---|---|
| onInit() | Called when a view is instantiated and its controls (if available) have already been created; used to modify the view before it is displayed to bind event handlers and do other one-time initialization |
| onExit() | Called when the view is destroyed; used to free resources and finalize activities |
| onAfterRendering() | Called when the view has been rendered and, therefore, its HTML is part of the document; used to do post-rendering manipulations of the HTML. SAPUI5 controls get this hook after being rendered. |
| onBeforeRendering() | Invoked before the controller view is re-rendered and not before the first rendering; use onInit() for invoking the hook before the first rendering |
| Please Note | Example |
|---|---|
| For controllers without a view, no lifecycle hooks are called. | sap.ui.controller("sap.hcm.Address", { onInit: function() { this.counter = 0; } }); |
Event Handlers and Other Functions In addition to lifecycle hooks, a controller can define additional methods that serve as event handlers or additional functionality offered by the controller. | sap.ui.controller("sap.hcm.Address", { increaseCounter: function() { this.counter++; } }); |
| Controller Conventions |
|---|
| Controller names are capitalized |
Controllers carry the same name as the related view (if there is a 1:1 relationship). |
Event handlers are prefixed with "on" e.g. onInit, onExit, onBeforeRendering, onAfterRendering |
| Controller names always end with *.controller.js |
Miscellaneous
An insight into SAPUI5 through free online resources
- SAP Managed Tags:
1 Comment
