Saphelp Ui

SAPUI5: UI Development Toolkit for HTML5
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_uiaddon20/helpdata/en/95/d113be50ae40d5b0b562b84d715227/content.htm
Created on January 26, 2017
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help
Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
The selected structure has more than 150 subtopics. This download contains only the first 150 subtopics. You can manually download the missing
subtopics.
2017 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP
SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are
provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set
forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional
warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in
Germany and other countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC Page 1 of 244

2014 SAP SE or an SAP affiliate company. All rights reserved.
Table of content
1 SAPUI5: UI Development Toolkit for HTML5
1.1 What's New in SAPUI5
1.1.1 What's New in SAPUI5 1.38
1.2 Read Me First
1.2.1 SAPUI5 vs. OpenUI5
1.2.2 Versioning of SAPUI5
1.2.3 Upgrading
1.2.3.1 Upgrading from a Version Below 1.38
1.2.4 Compatibility Rules
1.2.5 Supported Library Combinations
1.2.6 Deprecated Themes and Libraries
1.2.7 Browser and Platform Support
1.2.7.1 sap.ui.core, sap.ui.layout, sap.ui.unified
1.2.7.2 sap.m, sap.ui.table, sap.uxap, sap.tnt
1.2.7.2.1 Device-Specific Policies
1.2.7.2.2 Visual Degradations
1.2.7.3 sap.ui.comp
1.2.7.4 sap.viz
1.2.7.5 sap.ui.vbm
1.2.7.6 sap.ui.vk
1.2.7.7 sap.suite.ui.commons
1.2.7.8 sap.suite.ui.microchart
1.2.7.9 sap.ushell
1.2.7.10 sap.makit
1.2.7.11 sap.ui.commons, sap.ui.ux3
1.2.7.12 sap.gantt
1.2.8 Demo Kit and Platform-Specific Documentation
1.2.9 Development Environment
1.2.9.1 App Development Using OpenUI5
1.2.9.2 App Development Using SAP Web IDE
1.2.9.2.1 Get a Trial Account and Access SAP Web IDE
1.2.9.2.2 Start SAP Web IDE
1.2.9.2.3 Create a neo-app.json Project Configuration File
1.2.9.2.4 Create an index.html File
1.2.9.2.5 Run the App
1.2.9.2.6 Create a Northwind Destination
1.2.9.3 App Development Using SAPUI5 Tools for Eclipse
1.2.9.3.1 Installing SAPUI5 Tools for Eclipse
1.2.9.3.2 Using SAPUI5 Tools for Eclipse
1.2.9.3.2.1 Create an SAPUI5 Application Project
1.2.9.3.2.2 Add a Control to Your View
1.2.9.3.2.3 Implement a Method in the Controller
1.2.9.3.2.4 Create an Additional View
1.2.9.3.2.5 Integrate a New View
1.2.9.3.2.6 JavaScript Code Completion
1.2.9.3.2.7 Linking your Eclipse Editor to the Demo Kit
1.2.9.3.2.8 Use JavaScript and XML Templates
1.2.9.3.2.9 SAPUI5 Snippets
1.2.9.3.2.10 Running an App in the Application Preview
1.2.9.3.2.10.1 Use a SimpleProxyServlet for Testing to Avoid Cross-domain Requests

1.2.9.4 Node.js-Based Development Environment
1.2.9.4.1 Installing the Node.js-Based Development Environment
1.2.9.4.2 Testing SAPUI5
1.2.9.4.3 Common Installation Issues
1.2.9.5 Development for Hybrid Web Containers
1.2.9.6 SAPUI5 Runtime Installation (SAP NetWeaver 7.3 EHP1 or Lower)
1.3 Tutorials
1.3.1 Hello World!
1.3.1.1 Step 1: Create an HTML Page
1.3.1.2 Step 2: Initialize the App
1.3.1.3 Step 3: Add Content Pages
1.3.1.4 Summary
1.3.2 Walkthrough
1.3.2.1 Step 1: Hello World!
1.3.2.2 Step 2: Bootstrap
1.3.2.3 Step 3: Controls
1.3.2.4 Step 4: XML Views
1.3.2.5 Step 5: Controllers
1.3.2.6 Step 6: Modules
1.3.2.7 Step 7: JSON Model
1.3.2.8 Step 8: Translatable Texts
1.3.2.9 Step 9: Component Configuration
1.3.2.10 Step 10: Descriptor for Applications
1.3.2.11 Step 11: Pages and Panels
1.3.2.12 Step 12: Shell Control as Container
1.3.2.13 Step 13: Margins and Paddings
1.3.2.14 Step 14: Custom CSS and Theme Colors
1.3.2.15 Step 15: Nested Views
1.3.2.16 Step 16: Dialogs and Fragments
1.3.2.17 Step 17: Fragment Callbacks
1.3.2.18 Step 18: Icons
1.3.2.19 Step 19: Reuse Dialogs
1.3.2.20 Step 20: Aggregation Binding
1.3.2.21 Step 21: Data Types
1.3.2.22 Step 22: Expression Binding
1.3.2.23 Step 23: Custom Formatters
1.3.2.24 Step 24: Filtering
1.3.2.25 Step 25: Sorting and Grouping
1.3.2.26 Step 26: Remote OData Service
1.3.2.27 Step 27: Mock Server Configuration
1.3.2.28 Step 28: Unit Test with QUnit
1.3.2.29 Step 29: Integration Test with OPA
1.3.2.30 Step 30: Debugging Tools
1.3.2.31 Step 31: Routing and Navigation
1.3.2.32 Step 32: Routing with Parameters
1.3.2.33 Step 33: Routing Back and History
1.3.2.34 Step 34: Custom Controls
1.3.2.35 Step 35: Responsiveness
1.3.2.36 Step 36: Device Adaptation
1.3.2.37 Step 37: Content Density
1.3.2.38 Summary
1.3.3 Data Binding
1.3.3.1 Step 1: No Data Binding
1.3.3.2 Step 2: Creating a Model
1.3.3.3 Step 3: Create Property Binding
1.3.3.4 Step 4: Two-Way Data Binding
1.3.3.5 Step 5: One-Way Data Binding
1.3.3.6 Step 6: Resource Models
1.3.3.7 Step 7: (Optional) Resource Bundles and Multiple Languages
1.3.3.8 Step 8: Binding Paths: Accessing Properties in Hierarchically Structured Models
1.3.3.9 Step 9: Formatting Values
1.3.3.10 Step 10: Property Formatting Using Data Types

1.3.3.11 Step 11: Validation Using the Message Manager
1.3.3.12 Step 12: Aggregation Binding Using Templates
1.3.3.13 Step 13: Element Binding
1.3.3.15 Step 15: Aggregation Binding Using a Factory Function
1.3.4 Navigation and Routing
1.3.4.1 Step 1: Set Up the Initial App
1.3.4.2 Step 2: Enable Routing
1.3.4.3 Step 3: Catch Invalid Hashes
1.3.4.4 Step 4: Add a Back Button to Not Found Page
1.3.4.5 Step 5: Display a Target Without Changing the Hash
1.3.4.6 Step 6: Navigate to Routes with Hard-Coded Patterns
1.3.4.7 Step 7: Navigate to Routes with Mandatory Parameters
1.3.4.8 Step 8: Navigate with Flip Transition
1.3.4.9 Step 9: Allow Bookmarkable Tabs with Optional Query Parameters
1.3.4.10 Step 10: Implement Lazy Loading
1.3.4.11 Step 11: Assign Multiple Targets
1.3.4.12 Step 12: Make a Search Bookmarkable
1.3.4.13 Step 13: Make Table Sorting Bookmarkable
1.3.4.14 Step 14: Make Dialogs Bookmarkable
1.3.4.15 Step 15: Reuse an Existing Route
1.3.4.16 Step 16: Handle Invalid Hashes by Listening to Bypassed Events
1.3.4.17 Step 17: Listen to Matched Events of Any Route
1.3.4.18 Summary
1.3.5 Testing
1.3.5.1 Step 1: Overview and Testing Strategy
1.3.5.2 Step 2: A First Unit Test
1.3.5.3 Step 3: Adding the Price Formatter

SAPUI5: UI Development Toolkit for HTML5
You can use the UI development toolkit for HTML5 (SAPUI5) to create apps with rich user interfaces for modern Web business applications.
Apps developed with SAPUI5 present one consistent user experience. They are responsive across browsers and devices - they run on smartphones, tablets,
and desktops. The UI controls automatically adapt themselves to the capabilities of each device.
SAPUI5 offers powerful development concepts: Disclaimer: The below video is not part of the SAP product
Built-in extensibility concepts at code and application level documentation. Please read the legal disclaimer for video links
Data binding types and Model-View-Controller (MVC) before viewing this video.
Feature-rich UI controls for handling complex UI patterns and predefined layouts for typical
use cases.
Full translation support
Keyboard interaction support and accessibility features
And many more....
Check the SAPUI5 playlist in the SAP Technology YouTube

channel for the latest highlights videos!
SAP Fiori applications are built with SAPUI5. SAP Fiori apps follow the SAP Fiori Design Guidelines to ensure consistent design and a high level of design
quality. Explore the guidelines: https://experience.sap.com/fiori-design/.
For more information about SAP Fiori, see http://www.sap.com/fiori
What's New in SAPUI5

The following sections contain an overview of what's new in each version of SAPUI5, beginning with version 1.26.
In the following sections, we list the main new features and enhancements to SAPUI5. For a complete, detailed list of all new and enhanced functions, see the
Change Log in the Demo Kit.
SAPUI5 Highlights
Note
Check the SAPUI5 playlist in the SAP Technology YouTube channel for the latest highlights videos!
Disclaimer: The below video is not part of the SAP product documentation. Disclaimer: The below video is not part of the SAP product documentation.
Please read the legal disclaimer for video links before viewing this video. Please read the legal disclaimer for video links before viewing this video.
In this section:
1.1 What's New in SAPUI5 1.38
With this release the UI development toolkit for HTML5 (SAPUI5) is upgraded from version 1.36 to 1.38.
What's New in SAPUI5 1.36


Documentation Improvements
Thanks a lot to all of you who have used the Demo Kit feedback function! We have received lots of comments, many of which regarding our tutorials, and are
continuously improving the documentation based on your findings.
Please carry on giving us your feedback: even though we cannot update the documentation straight away, your feedback will be considered in the next
version!
New or reworked documentation chapters that are not mentioned in the following sections:
Chapter Routing and Navigation is now updated and reworked.
The Smart Controls tutorial now contains additional steps.
Deprecation
The following libraries are deprecated as of this version:
sap.ui.commons
sap.ui.ux3
sap.makit
The following themes are also deprecated as of this version:
sap_ux
sap_platinum
sap_goldreflection
For more information, see Deprecated Themes and Libraries.
jQuery Upgraded to Version 2.2.3

jQuery has been upgraded to version 2.2.3. This upgrade may have an impact on apps developed with SAPUI5. For more information, see the following
chapters:
Upgrading from a Version Below 1.38
New Features
We have 46 new icons, and some existing icons have been redesigned - check the Icon Explorer in the Demo Kit for details.
Multiple preprocessors for XML views
We have enhanced the XML view so that it is now capable of running more than one preprocessor per hook. Additionally, the new hook viewxml has
been introduced. For more information, see Preprocessing XML Views.
SAPUI5 OData V4 model
We are providing an initial version of the SAPUI5 OData V4 Model. This model supports the following:
Read access
Updating properties of OData entities via two-way-binding
Operation (function and action) execution
Grouping data requests in a batch request
Server-side sorting and filtering
Restriction
This is the first version of the SAPUI5 OData V4 model. Due to its limited feature scope, we recommend you do not use this release to develop
applications that are to be used in production systems. Please look at the detailed documentation of the features, as certain parts of a feature may
be missing which you might expect as given. While our intention was to be compatible with existing controls, existing controls might not work due to
small incompatibilities compared to sap.ui.model.odata.(v2.)ODataModel, or due to missing features in the model. Up to now, only limited
tests with controls have been done with the SAPUI5 OData V4 model. The interface for applications has been changed to make usage of the model
easier and more efficient. A summary of these changes is documented in the section Changes Compared to OData V2 Model.
For more information see OData V4 Model.

The annotations that are used by smart controls are now shown in the API Reference and are also explained in more detail. For more information, see
the documentation for the relevant controls in the API Reference for the sap.ui.comp library in the Demo Kit.
New Controls

sap.m.FormattedText: You can use this control to display formatted texts in HTML format.
sap.m.MenuButton: The control opens a hierarchical menu and enables quick triggering of the last action of the menu item selected. In Regular
mode it always opens the menu, whereas in Split mode it can be also used directly as a button to trigger the currently displayed menu items action.
In Split mode it can display either the default menu item or the last selected one.
Regular Mode Split Mode
sap.m.ObjectMarker: The ObjectMarker control represents the status of an object with icon and/or text. It can be interactive (as a link) or non-
interactive. It has the following predefined types:
Flagged
Favorite
Draft
Locked
Unsaved
An object might have multiple ObjectMarkers at the same time but the editing states (Locked, Draft, and Unsaved) are mutually exclusive.
sap.m.RangeSlider is a new input control that is used to select a range of values. The RangeSlider has two slider handles that can be moved
along a predefined numerical range scale. This control extends the sap.m.Slider and introduces additional functionality.
sap.m.StepInput: The StepInput control allows the user to change the input value with a predefined step. The value can be changed using the
increment/decrement buttons or keys on the keyboard. On the desktop, when using the keyboard PgUp and PgDn keys, the value increases/decreases
two steps at a time.
sap.ui.comp.smartmicrohart.SmartMicroChart: This control is used to create different types of micro charts based on OData metadata. With
this control, you can define annotations once for different micro chart types. The SmartMicroChart control contains a wrapper that interprets the chart
type of the Chart annotation and delegates this information to the corresponding smart micro charts, SmartAreaMicroChart or
SmartBulletMicroChart control.
sap.ui.comp.smartmicrochart.SmartBulletMicroChart: The SmartBulletMicroChart control creates a
sap.suite.ui.microchart.BulletMicroChart based on OData metadata and the user-specific implementation.
sap.ui.comp.SmartMicroChart.SmartAreaMicroChart: The SmartAreaMicroChart control creates a
sap.suite.ui.microchart.AreaMicroChart based on OData metadata annotations and the user-specific configuration.
sap.ui.layout.ResponsiveSplitter is a layout control that is used to visually divide the content of its parent. The control is responsive and can
adjust its contents to any screen size. On smaller screens, pagination is used to allow navigation to all splitter panes.

Visual Interaction toolkit (sap.ui.vk library): The following controls have been added:
sap.ui.vk.LayerProxy: The LayerProxy control allows you to create a proxy object for a layer, so that you can work with that layer in the
scene.
sap.ui.vk.ProgressIndicator: The ProgressIndicator control allows you to add a progress bar that indicates the download and
rendering progress of a file.
sap.ui.vk.Notifications: The Notifications control allows you to add an icon in your application that displays the number of errors and
warnings that may have resulted from loading a 2D image or 3D file. The icon can be clicked to display more information about the errors and
warnings.
Improved Features
One page acceptance test (OPA):
The Press and EnterText actions now support a larger number of controls and can now be executed on embedded controls by specifying the control
suffix.
SAPUI5 application index: The index is now based on the layered repository and is updated automatically in most cases. For the other cases we
recommend that you schedule the update report every 30 minutes using the default mode (expiration period of 24 hours). For more information, see
SAPUI5 Application Index.
Improved Controls
sap.m.ComboBox:
Is now supported on mobile phones. The list of available values will open as a full-screen dialog on small devices.
The new loadItem event makes it possible to defer initialization of items in the ComboBox dropdown list control to a point in time when the items
are required. This helps to improve performance.
sap.m.DatePicker, sap.m.DateTimePicker, sap.m.PlanningCalendar, and sap.ui.unified.Calendar: You can now set minimum and
maximum dates to limit the range of available dates.
sap.m.GenericTile: The GenericTile control has a new responsive design that significantly improves the user experience, it has also been
optimized for larger smartphones. The GenericTile adjusts its size to fit all the different display sizes of the current devices supported by SAPUI5
(see Browser and Platform Support). The main changes are the tile size, font size, padding, the new ImageContent control, and new samples showing
the variety of use cases for the GenericTile.

The sap.m.ImageContent control can be used to include images in a tile. It can be embedded in the content area of the GenericTile control.
For more information, see Generic Tile.
sap.m.List and sap.m.Table: The new keyboardMode property for the List and Table controls determines the keyboard handling for these
controls. The Navigation value of the property enables a mode that allows you to navigate within a large number of items, for example, table cells,
using the tab key, whereas the Edit mode can be used to edit a limited number of items.
sap.m.MaskInput: You can now use escape characters in the MaskInput definition to be able to use the predefined rule characters as immutable
ones.
sap.m.MessagePopover has been improved and can now be resized. Resizing is only possible when the MessagePopover is opened from the
footer on a desktop.
sap.m.NotificationListItem: The control has two improvements:

The control responsiveness is updated for better usability on large screens (more than 640 pixels width) the buttons are now located on the right
side of the text.
The Show More button for toggling expand/collapse mode can now be hidden with the use of the new property hideShowMoreButton.
sap.m.Popover has four new values for its PlacementType:
PreferredBottomOrFlip
PreferredLeftOrFlip
PreferredRightOrFlip
PreferredTopOrFlip
They determine the preferred position of the Popover and how it behaves when there is insufficient space for it on the screen. These properties allow
the Popover to flip over and cover some of the content below it.
sap.m.TextArea can now grow and shrink to adapt to the entered text.
sap.m.UploadCollection: To upload a new version of a file to the UploadCollection list, the openFileDialog method is available. You can
provide a pushbutton in the header area and if one entry in the UploadCollection list is selected, the API method will be called.
sap.m.ViewSettingsDialog: The ViewSettingsDialog control now gives you the opportunity to modify filter detail page items on the fly with
the help of the new event filterDetailPageOpened. This event is fired each time after the filter detail page is accessed, notifying the outside world
that the page is loaded along with the information for which filter the respective details are displayed. This allows a handler to be attached that alters the
filter detail items aggregation.
sap.suite.ui.microchart: The controls now have a responsive design and can adapt their appearance and functions either to the devices they are
used on or to the available space provided by the parent control.
sap.tnt.SideNavigation: Root items with no children can now be opened with a single click when the SideNavigation control is in collapsed
mode.
sap.tnt.ToolPage: Animation is now added when expanding and collapsing the SideNavigation control within the ToolPage.
sap.ui.commons.ColorPicker supports HSL (Hue Saturation and Lightness) mode. This mode works better with modern browsers and it does not
require intermediate conversion back to RGB. Additionally, there is a new input field for the alpha (transparency) value for more precise color definition.
sap.ui.comp (Smart Controls):

sap.ui.comp.smartchart.SmartChart:The SmartChart control now offers two additional features that you can switch on if you want to
use them. The control now provides the breadcrumb trail of a drilldown and also lets you drill upwards within that path.
The control also provides a changed drilldown function: When you select one or more data points, the Drill Down button becomes a Details
button. When you click this button, you will see more details related to the selected data. From here, you can also navigate to semantic objects,
for example, to related apps.
The usability of the chart type selection has been improved.
For more information about this control, see the API Reference and the sample in the Explored app in the Demo Kit.
sap.ui.comp.smartform.SmartForm: You can now set an XL breakpoint for the SmartForm control as you could previously only with the
sap.m.Form. sap.ui.comp.smartform.Layout now offers the properties labelSpan and emptySpan as well as columns and a
breakpoint also for screens of extra-large sizes.
sap.ui.comp.smarttable.SmartTable:
If you use the SmartTable control with a responsive table (sap.m.Table), and the columns contain a property annotated with
Criticality that returns the CriticalityType annotation, an ObjectStatus control is used to display the status. The application
using this control can control whether an icon is displayed by using the CriticalityRepresentationType annotation.
If you use the SmartTable control with a responsive table (sap.m.Table), and the cells contain the URL of an image, the image will
automatically be displayed in a default size of 3 rem using the IsImageUrl annotation.
If you use the SmartTable control with a responsive table (sap.m.Table), and the columns contain a property annotated with the
SemanticKey annotation, they will automatically be displayed as sap.m.ObjectIdentifier. The TextArrangement annotation
controls whether the ID and the description are displayed as the title of the ObjectIdentifier control and in which order. In addition, if
there is a link to SemanticObject, the ObjectIdentifier title will be clickable and display or navigate to the SmartLink targets.
A new property showFullScreenButton allows you to expand the table to full screen mode using the respective toolbar button.
The SmartTable control now allows you to show and follow navigationProperty fields for EntityType and automatically performs a

$expand operation for these fields.
If you group columns in the personalization of analytical tables, the grouping is now automatically added as a separate column ( Show Field
as Column checkbox). This allows you to see the grouped values for each row of the table.
For measure columns within an analytical table, the total sum of a column is now persisted in the variant of a table.
You can now create an additional title for the SmartTable control.
sap.ui.comp.filterbar.FilterBar:
If you add new filters from the fields listed, they will now be automatically visible on the expanded filter bar. You no longer have to select the
Add to Filter Bar checkbox.
You can now create an additional title for the FilterBar control.
sap.ui.comp.navpopover.SmartLink: If a SmartLink control has only one target, it will directly take you to the target of a link. In this
case, the popover will not be displayed.
sap.ui.comp.variants.VariantManagement:
You can now change the behavior of the SAP-delivered standard variant and select Execute on Select in the Manage Variants dialog.
This will fire the query automatically.
A page variant of the VariantManagement control is now available that can handle the persistency of multiple smart controls and provides
the variant management in a central place.
For more information about smart controls, see sap.ui.comp.
sap.ui.layout.Form and sap.ui.layout.SimpleForm: You can now add a toolbar to a form container or the form itself.
sap.ui.table.DataTable has been deleted.
sap.ui.table.TreeTable now supports AutoExpand paging if it is bound to an OData model.
By setting numberOfExpandedLevels as a binding parameter (e.g. in the bindRows call of the TreeTable), you now can specify the initial
expansion depth. This feature is only available for OData services exposing a property marked with the annotation hierarchy-node-descendant-
count-for. This also means the service has to respect a $filter statement on the annotated Level property, and returns the entries sorted. You
can find the specification for this and all other hierarchy annotations in the SAP Community Network under SAP Annotations for OData Version 2.0
sap.ui.unified.Menu: To significantly increase the usability of sap.ui.unified.Menu, a delay has been added to the closing of submenus.
sap.ui.vk.NodeHierarchy: The NodeHierarchy control now has a new method called findNodesById, which allows you to search for specific
nodes in a 3D scene using the VE ID data in nodes as the search parameter.
sap.uxap.ObjectPageHeader ObjectPageHeader can be integrated with the SideContent scenario. A new sideContentButton aggregation
has been added. This aggregation has a new button, which appears after the actions buttons and triggers opening the side content for additional
information.
sap.uxap.ObjectPageLayout:
It supports scrolling to a particular section, based on its ID. This allows easier access to all parts of the application and consistent navigation back
to a previous position within the ObjectPage.
Performance is improved for the use case with no Blocks. The ObjectPage now supports lazy loading with the stashed property of the
ObjectPageLazyLoader. As a result, you avoid the additional creation of XML views for each Block.
Smart Templates
General Features:
Actions for line items in tables
You can now enable certain types of actions within a line item column in a table in both the list report and object page views. Actions you can enable at
the line item level include those that trigger a back-end call through the OData service, for example, approve or unblock, or those that trigger navigation,
for example, to a different application.
Rating indicator in tables
You can now include a read-only rating indicator in the list report or in a table in the object page view. This allows you to visually represent the value of a
field with the corresponding number of stars (configurable). This field can indicate, for example, a rating or classification for a specific object or item.
Progress indicator in tables
You can now include a progress indicator in the list report or in a table in the object page view. This allows users to visualize the level of completion of,
for example, a project or a goal. Optionally, you can set up the following:
Whether a single color is used in the progress bar (default: blue), or multiple colors are used to indicate criticality (example: red to indicate that
stock levels are very low)
The value used to calculate the percentage value displayed
External navigation
You can now enable navigation from line items in a table to a different app using intent-based navigation. This feature is available for the list report and
tables in the object page view.
List Report View:
Deletion of one or more items
Users can now select and delete one or more items directly from the list report view.
Images in tables
You can now display images in table columns.
Harmonized variant management option
Variants created by the user for the smart filter bar and smart table can now be saved together using the variant for the smart filter bar.
Disabling editing status filter
You can disable the editing status filter for the list report.
Object Page View:
Image expansion
End users of your app can now click an image within the object page to see an expanded view of the image.
Plain text facet in object page header
You can now add a plain text facet to the header area of an object page. The plain text facet allows you to add a single field or block of text to the

header.
Smart chart in object page
You can now add a smart chart control to a facet in an object page. You specify the type of smart chart and, if desired, other chart data to be rendered in
your app through annotations in your service.
Editable header
You can now make fields in the object page header editable in edit mode by setting a parameter in the app descriptor.
Subsections: See more and See less
You can now hide subsections in facets and provide a See more / See less link for the facet.
Documentation Changes:
The following sections have been expanded and reorganized into subsections:
Which Smart Templates Are Available?
Preparing UI Annotations
Post-Generation Steps
Extending Generated Apps
Overview Pages
Overview pages have been enhanced with the following features:
Selection fields: With the UI.SelectionFields configuration in the annotations file, you can define the filter you want to add to the filter bar by
default.
Data points: Now, you can display as many data points as are present in the backend, in card charts. To limit the number of records, adjust the value of
the UI.PresentationVariant.MaxItems property in the annotion file (donut charts use all records, so this limitation isn't needed).
You can now create the following cards:
Column Chart Stacked Column Chart Vertical Bullet Chart
Data, such as total product sales over a period of A stacked column chart is similar to the column chart; With a vertical bullet chart, you can visualize a single
years, can be displayed in a column chart. The however, it visualizes multiple measures or measure and compare it to a defined reference
number of columns is equal to the number of dimensions by stacking the data on top of each other value, such as a target unit of measure. This target is
measures in the annotation file. in a column. displayed a solid black line.
For more information on these charts, see Analytic Cards

To improve your user experience with overview pages, we've also made several improvements:
Axis titles: The x- and y-axis of analytic chart cards won't be shown (except with a bubble chart) if you use a header for your card. If your header
contains a good description of the card, then the x- and y-axis descriptions are superfluous. Of course, you'll see both the x- and y-axis if you choose to
omit the header.
Quick view cards:
Interaction buttons in the footer area are now part of sap.m.OverflowToolbar. With this, the quick view cards can now display action buttons
based on the width of the card. If more actions are necessary, they will be shown on the overflow toolbar.
Since the height of each quick view card is aligned with the content of the card, this means cards can have different sizes. If there is more content
than can be shown in the card then you'll be able to scroll vertically, but only within the content area itself. The headers and footers stay fixed.
Related Information
Upgrading
Deprecated Themes and Libraries
OData V4 Model
Changes Compared to OData V2 Model
Preprocessing XML Views
SAPUI5 Application Index
sap.ui.comp
Smart Controls Tutorial
Analytic Cards

New Features
The OData Model V2 now supports binding against function import parameters. If the function import returns result data, then this result data can also
be accessed and bound. For more information, see OData V2 Model.
You can use jQuery.sap.measure to measure the performance of your JavaScript code. You can retrieve the results via APIs. You can calculate
averages and use filters or categories. For more information, see Performance Measurement Using jQuery.sap.measure.
New Controls
Gantt charts are a state-of-the-art function that can be used in various application domains, particularly in planning and scheduling. In resource-based
planning, for instance, a Gantt chart can be used to show the plan using intuitive graphics, making it easier to view resource availability. In addition, it
also helps when monitoring the actual execution of the plan and enables interactive resource-based planning by drag&drop. In project management, it is
often used to display the project structure in a hierarchical way, showing milestones and relationships between activities.
The GanttChart control provides a rich set of features, such as displaying one or more Gantt charts, various events for user interaction (e.g.
drag&drop or mouse click events), multiple basic shapes (e.g. rectangles, milestones, triangles, relationships) and more sophisticated shapes (e.g.
utilization line chart, utilization bar chart) drawn in the chart area, comprehensive tree table features provided by the underlying TreeTable control, and
powerful configuration capabilities (e.g. shape colors and patterns, application-specific buttons) as well as zooming and scrolling. In addition, a
consuming application can implement its own shapes for the chart area. The Gantt chart control does not contain any business logic, meaning
consuming applications have to define their own user interaction and business semantics.
sap.gantt.GanttChartWithTable: The GanttChartWithTable control contains a tree table to the left and a chart to the right. It can
display a data hierarchy in the tree table and visualize its specific data along a time axis in the chart area.
All controls that can be used inside the tree table are also supported in the Gantt chart.
The application can control the visibility of the toolbar above the tree table, the display of buttons and menu items, as well as the time axis
display, such as planning period and zoom level. The application can also control the display of shapes contained within the chart area, such as
shape types and colors.
sap.gantt.GanttChartContainer: The GanttChartContainer control contains more than one GanttChartWithTable control and a
global toolbar. It can affect the behavior of all embedded GanttChartWithTable controls, such as zoom level, view layout, and default
settings.
The global toolbar provides default buttons, such as buttons for zooming, settings, and layout. The application can define additional buttons or hide
default buttons as needed. Multiple views can be laid out vertically or horizontally, and the scrolling (both horizontally and vertically) can be
synchronized, depending on the settings. Default options are provided in the settings to control the behavior of the control, such as Indicate
Current Time , Show Cursor Line , Show Divider Line , Synchronize Time Scroll , and Synchronize Row Scroll .

RadialMicroChart: You can use the new RadialMicroChart to display values in a circular chart with a percentage value in the center.
Different properties are provided allowing you to configure the percentage value. The control supports a responsive design. Depending on the available
space and favored size of the chart, you can influence the chart's size and representation. You can also use a property to define the color of the circle.
Improved Features
Performance improvements:
When possible, data requests will now be send out before rendering is triggered to improve overall end-to-end times.
Initial auto-expand to n levels is now supported in TreeTable for OData-based services with fewer requests based on a new OData annotation.
Relative time formatter for sap.ui.core.format.DateFormat: The new formatting options short and narrow for the relativeStyle allow a
concise display of a relative date like 3 years ago or 2 hours ago.
ABAP NUMC types are now supported in annotation processing and OData types as follows:
ABAP NUMC types can be represented in OData services as Edm.String with OData v2 SAP Extension 'sap:display-
format="NonNegative"' and constraint 'maxlength' set.
ODataMetaModel also provides the OData v2 SAP Extension 'sap:display-format="NonNegative"' as v4 annotation
'"com.sap.vocabularies.Common.v1.IsDigitSequence": { "Bool" : "true" }'. For more information, see Meta Model for
OData V2.
AnnotationHelper.format considers the 'com.sap.vocabularies.Common.v1.IsDigitSequence' annotation and 'maxlength'
constraint when creating a binding. For more information, see Annotation Helper.
sap.ui.model.odata.type.String reacts to the 'com.sap.vocabularies.Common.v1.IsDigitSequence' annotation and
'maxlength' constraint when processing its values.
Improved Controls
sap.m.FlexBox: The FlexBox control now allows wrapping items into multiple lines and influencing the layout of these lines. The sizing behavior of
flex items can be adjusted with minimum or maximum width and height values.
sap.m.MultiInput: This control now has the new property maxTokens, which defines the maximum number of tokens that are allowed within the
MultiInput.
sap.m.SearchField: This control now has a new suggestions feature. When a user enters something in the search field, the application can now
display a list of suggestions.
sap.m.TimePicker: A user can now edit or delete values directly from the input field on mobile devices.
sap.m.UploadCollection: You can now download an item from the upload collection list. For this feature, two new methods have been added, one
to the UploadCollection and the other to the UploadCollectionItem. This means you can choose from where you want to call the method. Both
methods allow you to define if the default download location of the browser is used or if the file dialog is called via a parameter to store to a different
location. For more information, see Upload Collection.
sap.m.Wizard: You can now add titles for steps (in addition to icons) that are shown in the progress navigator of a wizard. Titles help users to relate
the progress navigation part to the step content easily.

sap.ui.layout.DynamicSideContent: You can now configure the position of the side content to appear either to the left or to the right of the main
content.
sap.ui.layout.form.Form and sap.ui.layout.form.SimpleForm: Toolbars can now be used in Form or FormContainer headers.
sap.ui.layout.form.SimpleForm: This control now has the new property backgroundDesign, which can be used to switch between different
backgrounds.
sap.ui.comp.smartchart.SmartChart: The SmartChart control now allows you to navigate to the related semantic object for your chart when
you select the relevant part of the chart, such as a column. For this purpose, the SmartLink control has been implemented along with a new button
( Jump To ) in the toolbar.
In addition, the control provides the following new features in the toolbar:
Chart type shown as icon
Zoom in and out
Maximize and minimize
Toggle legend visibility
All actions performed in the chart itself (rather than in Settings ) can now also be saved as variants.
sap.ui.comp.smartform.SmartForm: The adjustLabelSpan and singleContainerFullSize properties of SimpleForm have been added
to the SmartForm control.
sap.ui.vk library: The following improvements have been implemented in the visual interaction toolkit:
The NodeHierarchy control now has the new methods fineNodesByName and findNodesByMetadata, which allow you to search for
specific nodes in a 3D scene.
The NativeViewport control now allows for viewing a wider range of file formats that are natively-supported by browsers. For more information,
see Native Viewport.
App Templates
The app templates now have an option to generate apps that run standalone, independently of the SAP Fiori launchpad. When used in this way, apps get a
separate index.html file to start the app. For more information, see App Templates: Kick Start Your App Development and Folder Structure: Where to Put
Your Files.
Smart Templates
Extensibility: The metadata-driven smart templates provide a variety of screen configurations. To further increase flexibility for developers, we have
introduced extension points, where you can add your own views and controller extensions using a new API interface.
Easier navigation in object page: In child object pages, breadcrumb-like navigation allows easy access to parent object pages.
New default filter option for draft handling: In the list report, you have a new default filter option that allows you to filter by draft document status.
Subsection in sections: You can now create subsections within a section of an object page.
Overview Pages
Overview pages now support conditional formatting. For example, using the SAPUI5 formatter, cards in overview pages can now show 1K instead of
1000 .
You can now display numeric KPIs in the headers of all card types, not just analytic cards. The number displayed in a KPI header is derived from an
aggregation of values in the OData service, as defined in the manifest.json file. In addition, the header displays a title, the unit of measurement, the
trend, and percentage of change.

Object streams opened from stack cards can now be comprised of any type of card, not only quick view cards one type per object stream. For
example, clicking on a stack card can open a stream of list cards or table cards.
You can now navigate from cards directly to a URL destination, in addition to intent-based navigation to applications.
When opening an overview page from another application, you can use URL parameters to open the overview page in context of that application. The
URL parameters are passed on to the global filter to obtain a relevant, cohesive view of the data.
Cards now support the following OData capabilities: $filter, sort and $select.
Browser and Platform Support

As of this version, SAPUI5 supports Microsoft Windows 10, Microsoft Internet Explorer 11, Microsoft Edge, Edge on touch devices, Edge on Microsoft
Windows Phones, and SAP Fiori Client 1.6.

Security Vulnerability Fixed

A security issue has been identified and fixed. For more information, see SAP Note 2204160 .
Tutorials
Mock Server: In this tutorial we'll explore some advanced features of the mock server. If no OData service is available or if you simply don't want to
depend on the OData back-end connectivity for your development and tests, the mock server can mimic the OData back-end calls: Mock Server.
Worklist App: In this tutorial we'll build a simple worklist app using the worklist app template. This app could be used by a shop owner to manage his
product stock levels, for example: Worklist App.
3D Viewer: In this tutorial you'll learn how to create applications with 3D viewing capabilities using the controls in the Visual Interaction toolkit
(sap.ui.vk library): 3D Viewer.
Walkthrough: The Walkthrough tutorial has been updated with some corrections based on user feedback. Many thanks to all readers who got in
touch with us! Steps 26 and 27 in particular have been completely rewritten: Walkthrough.
New and Improved Features

ODataTreeBinding: ODataTreeBinding supports server-side application filters which should be used for the $count/$inlinecount and data-
retrieval in operation mode "auto". This helps to reduce the amount of data that is processed later on in the client and thus improves the
performance.
Support for sequentialized asynchronous OData requests: With the OData model V2, you can now use the new sequentializeRequests setting
to sequentialize asynchronous requests for OData providers that cannot handle multiple parallel requests at the same time.
One page acceptance test (OPA):
Starting a UIComponent using iStartMyUIComponent: You can now run OPA tests in the same frame or window. For more information, see
Getting Started with OPA5.
Actions: Did you always find it difficult to press a button or insert a text into an input field when writing your OPA tests? Starting with this SAPUI5
version, the first two OPA actions Press and EnterText are available to make your life easier.
App templates: We added some minor improvements to the app templates, like asynchronous view creation in routing, and updated the version of the
application description (manifest.json). For more information, see App Templates: Kick Start Your App Development.
SAPUI5 application index: The application index is now updated automatically after an import if the Business Add-In CTS_IMPORT_FEEDBACK is
called. The documentation also contains detailed information indicating when the application index is updated automatically and when you have to
schedule the calculation report manually (and in what mode). For more information, see SAPUI5 Application Index.
Whitelist Service for SAPUI5 Clickjacking Framing Protection: As described in SAP Note 2245332 , you can use a whitelist service for
clickjacking framing protection to guard SAPUI5 apps. Just configure the whitelist service as described in SAP Note 2142551 . SAPUI5 apps can
then only be used in an iFrame if the host server was specified in the whitelist.

New Controls
sap.m.Breadcrumbs: A breadcrumb is a type of secondary navigation that indicates the page's position in the site hierarchy. These visual aids
indicate the user's location within the site hierarchy and helps them find their way around. Breadcrumbs are always located at the top left side of the
page.
sap.m.MaskInput: The sap.m.MaskInput control is used to govern what a user is allowed to enter in an input field. The mask has a fixed length
format set upon instantiation and the user input has to conform to it. We recommend using this when the user enters text or numbers with specific
formatting, such as a phone number, ZIP code, credit card number, etc.
When creating a new mask, you can change the configuration of some default properties. For example, the default placeholder symbol _ can be changed
to something else. Note that the sap.m.MaskInput control extends sap.m.Input and has all the normal properties of an input field.
sap.m.NotificationListGroup: The NotificationListGroup is a control used to group a list of NotificationListItems. The group
consists of a header containing title, group's author picture, group's author name, time stamp and a priority stripe, a body containing a list of
notifications, and a footer containing a collapse/expand button, list of action buttons and a priority stripe. The sap.ui.core.Priority property
defines the priority of the group, which can either be defined by the developer or automatically calculated by the group (based on the highest priority of
its notifications).
sap.m.NotificationListItem: The NotificationListItem is a control used to display a notification, and it extends the ListItemBase
control. The notification consists of a title, description, author picture, author name, time stamp, priority, close button and a list of action buttons. All
these parts are both optional and configurable. The sap.ui.core.Priority property defines the priority of the notification and is visualized on the
left side of the container with a stripe displayed in a different color depending on the priority.

sap.m.PlanningCalendar: You can use the planning calendar to show the appointments of team members in a specified time period.
sap.m.TabContainer: The sap.m.TabContainer control is a generic tab container for managing multiple tabs.
The control contains a TabStrip area where the user can choose which tab to read or edit. Every tab has a close/decline button (visible on mouse
hover) that removes the item from the screen and an asterisk (*) indicator that notifies if there are unsaved changes in a particular tab. This can be
handled by the application developer. In order to navigate through many tabs, there are also left and right arrows. New tabs can be easily added using
the + button in the upper right corner.
Another way for users to find their tab is to look in the Select list where all the tabs from the TabStrip are listed.
GenericTile control moved to sap.m: With this release, the GenericTile, TileContent, FeedContent (formerly JamContent),
NewsContent, NumericContent, and SlideTile (formerly DynamicContainer) controls have been moved from the sap.suite.ui.commons
library to the sap.m library.
If you have already included one of these controls before SAPUI5 1.34, a wrapper ensures that the embedding still works for each control. To benefit
from all the enhancements or new features for one of these controls as of SAPUI5 1.34, you need to switch to the controls in the sap.m library. With
SAPUI5 1.34, all these controls in the sap.suite.ui.commons library are marked as deprecated.
During the move, the following controls have been renamed:
JamContent to FeedContent
DynamicContainer to SlideTile
For more information, see Generic Tile.
sap.ui.comp.smartchart.SmartChart: The SmartChart control can be used to create complex diagrams. You can select a chart type, such as

a pie chart, column chart or a chart with an x and a y-axis or two y-axes, and define the dimensions and measures for your chart and how you want to
display them. A drilldown enables the user to display even more information about a dimension.
Further features are provided by using other smart controls in combination with the SmartChart control: You can save a chart as a variant using the
SmartVariantManagement control or make chart-specific personalization settings using the sap.m.P13nDialog control.
In the personalization dialog, a new Chart panel has been added. You can also sort the data in your chart or filter it based on the conditions you define.
New sap.suite.ui.microchart library: With the new MicroChart library (sap.suite.ui.microchart), all the available MicroChart
controls of the sap.suite.ui.commons library have been moved to their own library.
If you have already included a MicroChart control before SAPUI5 version 1.34, a wrapper ensures that the embedding still works for each control. To
benefit from all the enhancements or new features for the MicroChart controls as of SAPUI5 1.34, you need to switch to the controls in the new
library. With SAPUI5 1.34, all the MicroChart controls in the sap.suite.ui.commons library are marked as deprecated.
During the move, the following controls and their elements have been renamed:
MicroAreaChart to AreaMicroChart
ComparisonChart to ComparisonMicroChart
BulletChart to BulletMicroChart
For more information, see sap.suite.ui.microchart .

New Library sap.tnt: This new library contains controls that provide the basic structure of a tools app.
sap.tnt.NavigationList: An control which provides a choice of different items ordered as a list. The navigation has a maximum of two
levels - the items can have subitems but subitems cannot have other subitems. NavigationList items that contain subitems can be expanded
or collapsed.
sap.tnt.SideNavigation: A container which consists of flexible and fixed parts, where each part contains a NavigationList. When there
is not enough space for the items in the flexible part, a vertical scrollbar appears. On tablet devices, the scrollbar is replaced by scroll arrows but
scrolling via swipe is also available. When the height of the whole control is less than 256px, the scrollbar becomes joined for the two parts. The
SideNavigation has two modes: expanded and collapsed.
sap.tnt.ToolHeader: A horizontal container based on sap.m.OverflowToolbar. It is most commonly used to display buttons, labels,
selects and other various input controls. In addition, the ToolHeader allows the developer to specify where the overflow button is placed via the
ToolHeaderUtilitySeparator class.
sap.tnt.ToolPage: A layout control used to put together the parts of a basic tools app - ToolHeader, SideNavigation and content area.
The ToolPage control also checks the type of the device on which it is displayed and sets the expanded state of the SideNavigation. This
can be controlled by the developer using the sideExpanded property of the ToolPage.

sap.ui.layout.BlockLayout: You can use the BlockLayout control to display several objects in different visual sections. This control features
horizontal and vertical subdivisions and full-width banners as seen frequently in contemporary Web design. Background colors are attached directly to
these blocks of the layout. By placing pictorial and textual elements side by side in different blocks, a relation of content is established. Special full-
width sections of the BlockLayout allow horizontal scrolling through a set of blocks. In our Demo Kit the BlockLayout serves as a flexible container
for diverging content, such as headings, explanatory texts, code snippets, remarks, and examples. You can use the BlockLayout control to display
diverging objects on one page. We recommend that you do not use BlockLayout to display properties or features of one content item but use the
ObjectPage instead. This control also has the option of switching between two backgrounds - one is transparent and the other uses four predefined
colors. These are automatically mapped to the different blocks and their arrangement helps to optically separate and decouple the contents of the single
blocks.

Smart Templates and Overview Page
The smart templates have been enhanced with the following new features:
Status colors and icons: To emphasize the criticality of specific status fields or values, a criticality property has been added to the corresponding
fields.
Value help as dropdown list box: If the entity set of a value help has a stable number of instances, you can render an input field with a value help and
a dropdown list box (sap.m.ComboBox and, in cases of multi-selection, a sap.m.MultiComboBox).
Header facets: You can use the annotation term UI.HeaderFacets to define which information is to be displayed in the header. For example, you can
now define content blocks with several fields and contact details. In addition, you can apply content blocks for the shipping address, price, and category.
Editable table in object page: In Edit mode, you can now change the values in table fields on the object page directly. The new feature works with
draft-enabled object pages and with editable fields only. You cannot use this function to make display fields editable.
Multi-select single-action: You can now select multiple items on the list report and execute an action. If applicable, the system then displays a
message dialog with error information for the selected items.
Full user name in draft administrative data: For drafts with unsaved changes or status Locked in the list report, the corresponding popover now
displays the first name and surname of the user who last changed the item. For the object page, the feature is also available. You can display the full
administrative data by clicking on the Status icon in the header next to the title.
Share menu in object page: The object page now supports the Share menu which is rendered in the object header. The menu contains the actions
Send Email and Save as Tile . In addition, if SAP Jam is configured accordingly in your system, the menu can also display the Share in Jam action.
Enable light theme in the object page header: The object page now supports the light header theme together with highlighting and semantic colors.
The semantic colors are essential for the correct display of many header facets, for example numeric values, or status as key figures.
Navigation Service
This new service allows cross-application navigation referencing a semantic object in another application and can, for example, be used by the smart
templates. It uses the sap.ushell.services.CrossApplicationNavigation navigation service. The following artifacts are available in
sap.ui.generic.app:
sap.ui.generic.app.navigation.service.NavError
sap.ui.generic.app.navigation.service.NavigationHandler
sap.ui.generic.app.navigation.service.SelectionVariant
Overview Page
For the overview page, we added the following features:
Personalization: End users can now change the order of cards on the overview page by dragging and dropping cards and they can define which cards
are displayed on the overview page using the new Manage Cards entry in the Options menu.
Accessibility: Overview pages now support the High Contrast Black theme, as well as other accessibility features such as keyboard navigation and
screen reader support.
Globalization: Support for right-to-left languages has been added.

Improved Controls
sap.m.ComboBox: You can now use the sap.m.ComboBox to display additional information with a second column by setting
"showSecondaryValues".
Support of Japanese Emperor calendar in sap.m.DatePicker and sap.ui.unified.Calendar: In the Japanese Emperor Calendar, a new era
starts if there is a new emperor. Both sap.ui.unified.Calendar and sap.m.DatePicker now support the Japanese Emperor Calendar.
sap.m.MessagePopover: The MessagePopover control now supports automated extraction of the longTextURL if the user uses GET requests in
the back end and automatic binding to the default message model.
sap.m.OverflowToolbar: The OverflowToolbar control has been visually restyled and improved as follows:
The default button style is now represented in the OverflowToolbar popover as a transparent button.
The popover arrow has been removed in favor of just a subtle offset.
The popover now appears either on top of or below the "..." (See more) button. In addition, its right side (or respectively its left side in RTL mode)
is aligned with the button's edge.
sap.m.Page: The sap.m.Page control accessibility is now extended with page landmark support. These landmarks are used, for example, by
assistive technologies (like screen readers) to provide a meaningful page overview.
sap.m.TimePicker: The scroll values can now be scrolled with the mouse wheel on mouse hover.
Smart correction of the value is now available when the user input does not conform to the defined time format but still matches default fallback time
format. Example: If the user enters 12:-- -- in an empty TimePicker input field and presses Enter, the value becomes 12:00 PM automatically.
sap.m.UploadCollection: You can use a customizable toolbar instead of the aggregation toolbar in the UploadCollection control. To get the
customizable toolbar, the aggregation toolbar has to be set to the sap.m.OverflowToolbar control that can be filled with your preferred SAPUI5
controls. To configure the position of the Add ( + ) pushbutton, the sap.m.UploadCollectionToolbarPlaceholder type was implemented.
The new mode property with the following values has been implemented: None, SingleSelect, MultiSelect, SingleSelectLeft,
SingleSelectMaster. The mode property defines the selection mode of the UploadCollection control.
sap.suite.ui.microchart.BulletMicroChart: The available theme-specific background color transparent of the CommonBackgroundModeType type
is now supported for the scaleColor property.
Time in smart controls in sap.ui.comp library: >The SmartField, SmartFilterBar, and SmartTable controls now support the Edm.Time
OData type. The fields bound to OData properties of this type are represented by the sap.m.TimePicker control. In particular, the filter panel showing
the conditions in the SmartFilterBar control allows filtering for time types using the TimePicker control.
Filtering in smart controls in sap.ui.comp library: Support of Boolean filters has been improved by using texts as defined in the Boolean OData

type.
sap.ui.comp.smartfield.SmartField: The new ObjectStatus class of the SmartField control provides status control and gives the option
to display status icons based on the UI annotation UI.CriticalityType.
sap.ui.comp.smarttable.SmartTable: The fieldChange event has been added to the SmartTable control. It passes on changes of editable
fields that have been created internally by the SmartTable control.
SortOrder of the PresentationVariant annotation is now taken into account for the SmartTable control.
sap.ui.comp.smartfilterbar.SmartFilterBar: A validation is now performed for entries made in the relevant MultiInput controls of the
SmartFilterBar control before the user presses Go .
sap.ui.comp.smartvariants.SmartVariantManagement: Key users can now modify and save a standard variant that is then stored in the
layer of the SAPUI5 flexibility services.
Basic search values are now stored as part of the variants. .
sap.ui.layout.SimpleForm: The SimpleForm now supports XL breakpoints when using sap.ui.layout.form.ResponsiveGridLayout.
sap.uxap: The sap.uxap library that contains the ObjectPage is now also part of the runtime library. Apart from that, the ObjectPage has been
enriched with several new features:
Lazy loading enabled for IconTabBar mode: The lazy loading feature used to work in the default AnchorBar mode only and was designed to
delay the loading of Blocks that are not yet in the viewport. The same now holds true for IconTabBar mode: Blocks that are in other tabs or in
the current tab, but are not in the viewport, will be lazy loaded.
Expand header with a click: An Expand Header button has been added to the ObjectPageHeader. This makes it possible to show the whole
header content even when the user has scrolled down. When you click this button, it disappears and the header content is expanded. If you
continue scrolling down, the button becomes visible again.
Subnavigation in IconTabBar mode: When in IconTabBar mode, the ObjectPage used to only separate sections in different tabs without
providing further navigation inside a tab. It is now possible to get a popover to navigate to a subsection when clicking on a tab for a section with
multiple subsections.
Content header always expanded: A new alwaysShowContentHeader property has been added to the ObjectPage. When set to true, the
ContentHeader will remain expanded even if the user scrolls down the page.
Note
This property is considered for desktop only. On mobile devices, the header always needs to snap because of the limited space.
Edit Header button: You can now add an Edit Header button. This is not an action button but rather a special button that provides a unified
interface for applications using the ObjectPage to switch to edit mode.
Unsaved changes indicator has been added to the ObjectPageHeader.
The new markChanges property enables the icon shown in the image above. A callback is also provided to handle the icon's click event.
Note
markChanges is mutually exclusive with markLocked.
Importance for ObjectPageHeader actions: You can now set priorities (High, Medium, Low) to action buttons, similarly to how importance works
for Sections and Subsections. For example, to make an action button overflow first, mark it with low importance like this:
<ObjectPageHeaderActionButton icon="sap-icon://action" text="action" importance="Low"/>
Apart from the features described above, several visual enhancements to the ObjectPage have been added, such as child page indication, an
indication that a section has subsections, and improved AnchorBar navigation.
Documentation and Demo Kit Improvements

We've noticed that the Demo Kit is increasingly becoming the first and sometimes only point of access to our documentation, regardless of the area in which
SAPUI5 is used.
As of this version, we therefore decided to include all of our documentation into the Demo Kit. This means that you can now find chapters that are only
relevant for developers working with SAP NetWeaver AS for ABAP or SAP HANA in all SAPUI5 Demo Kits, especially in our SAPUI5 Demo Kit for the SAP
HANA Cloud Platform, which you can find under https://sapui5.hana.ondemand.com.
Furthermore, we'd like to highlight the following new and reworked topics:
SAPUI5 vs. OpenUI5
Device Adaptation: Using Device Models for Your App
Performance: Speed Up Your App
Performance Issues
Components
Busy Indicators
Before this version, these topics were only available in the platform-specific documentation version (see Demo Kit and Platform-Specific Documentation).

We now use the feedback service that is available on the SAP HANA Cloud Platform also in the Demo Kit. The service provides a channel for you to send
feedback regarding the controls, samples and documentation. Just try it out - we're very interested in your opinion!

New Tutorials
Testing
In this tutorial, you learn how to test application functionality using the testing tools that are delivered with SAPUI5. While going through the steps of this
tutorial, you will write tests using QUnit, OPA5, and the mock server. Additionally, you will learn about testing strategies, Test Driven Development (TDD), and
much more: Testing
Smart Templates
App developers can use smart templates to create SAP Fiori applications based on OData services and annotations requiring no JavaScript UI coding. An app
based on smart templates uses predefined template views and controllers that are provided centrally, so no application-specific view instances are required.
The SAPUI5 runtime interprets metadata and annotations of the underlying OData service and creates the corresponding views for the SAP Fiori app at
startup.
The predefined view templates and controllers ensure UI design consistency across similar apps. Additionally, the metadata-driven development model
significantly reduces the amount of frontend code per app, so the developer can focus on the business logic.
Smart templates comprise templates for "List Report" and "Object Page".
For more information, see Developing Apps with Smart Templates.
New Libraries for Draft Handling and Smart Template Reuse Components
The new libraries sap.ui.generic.app and sap.ui.generic.template are now available. sap.ui.generic.template uses
sap.ui.generic.app and provides template reuse components, such as TemplateComponent, which creates and initializes smart template
components.
In particular, the following artifacts are available in sap.ui.generic.app:
sap.ui.generic.app.transaction.TransactionController
This class provides an API with reusable client logic for applications. The class is used for submitting changes, invoking actions and OData CRUD
operations in general, and triggering client-side validations. The TransactionController can be used by applications that are based on smart
templates and also by any SAP Fiori app or SAPUI5 user interface.
sap.ui.generic.app.transaction.DraftController
This class implements the transactional interaction patterns specified for OData services supporting draft documents and provides methods for draft-
specific actions. The TransactionController and DraftController classes and their related entities enable runtime draft handling for
applications.
sap.ui.generic.app.navigation.NavigationController
This class handles all navigation-related and routing-related tasks for the applications.
sap.ui.generic.app.AppComponent
This class interprets the configuration contained in the application descriptor.
Overview Pages
Overview Pages
An overview page is a SAP Fiori application, based on OData services and annotations, which provides an overview of a specific area and enables end users
to interact with business data and perform key actions.
The overview page application is comprised of the following:
Application header: provides a description of the area for which this application is providing an overview. The header also includes some general
application actions.
Card templates: a card is a smart component that uses UI annotation to render its content. Each card is bound to a single data source.
Global filter: provides the application-level filters that affect all cards in the overview page.
The sap.ovp library is now available with this version. This library provides template reuse components, such as the different card types and an application
template thatcreates and initializes the cards in the application.
App developers can create overview pages using the Overview Page wizard in SAP Web IDE.
For more information, see Overview Pages: Create Interactive Overviews of a Subject Area
UI5 Inspector
An open source Google Chrome Developer Tools extension that helps app developers to inspect, analyze and support SAPUI5-based apps. It offers the
following key features:
Inspect SAPUI5 controls and review their properties, bindings, and data model
Modify control properties on-the-fly and see how this affects the rendering and behavior
Find relevant framework information for SAPUI5-based apps
The UI5 Inspector can be downloaded as a standard extension from the Chrome Web Store . Once installed, it is then available in the Google Chrome
developer tools (by choosing F12) and becomes active when an SAPUI5 app is loaded.
For more information, see UI5 Inspector.
New Controls
Visual Interaction toolkit (sap.ui.vk library):
The Visual Interaction toolkit (sap.ui.vk library) provides controls that enable the visualization and manipulation of 3D models in your browser. The
controls in the toolkit allow you to:
Specify the content resources to be loaded into the Viewer, how those resources are loaded, and the locations to load resources from
Display the tree of nodes from your model
Display procedures and steps in a 3D scene, and play these procedures and steps
More features are available in addition to the ones described in the preceding list. For a full list of controls in the sap.ui.vk library and a detailed
description about how to use each control, see the API Reference for sap.ui.vk in the Demo Kit.
You can easily get started with the Visual Interaction toolkit using the Viewer control - a composite control that connects and presents the essential
Visual Interaction toolkit controls. The Viewer control can be configured to specify which controls to display by default. The following screenshot shows
a simple Viewer application loaded with a 3D model. The application has been configured to display a Viewport, a SceneTree, and
StepNavigation.

The Visual Interaction toolkit supports the loading of the following file formats:
.vds
.png
.jpg
.gif
sap.m.TimePicker: A composite control, consisting of an input field used to type the time, and a dropdown, which contains the picker itself. The user
can enter the time using the keyboard on desktop devices.
In compact mode, the time-related fields can be easily and quickly filled by scrolling, tapping or using the arrows. A mask containing placeholder
symbols is integrated into the input field. This helps users to enter correct symbols and also validates them.
This control is responsive and works seamlessly on mobile devices.

sap.m.DraftIndicator: The DraftIndicator control shows the current draft state either saving or already saved. There is also an integration
use case that enables app developers to show a draft state inside the footer of the semantic page - this has been implemented as part of the draft
handling concept. The DraftIndicator does not block the current screen, meaning other operations can be triggered in parallel.

Improved Features
One Page Acceptance Tests (OPA)
To improve error handling, a test throwing an exception in OPAs check/success or matcher functions now fails immediately when the exception is
thrown. OPA will not execute further waitFor statements added by the failed test. Subsequent tests of a failed test will still be executed.
You can now use sap.ui.test.matchers.BindingPath to check whether a control has a binding context with the exact same binding path.
OPA is now compatible with QUnit 2.x. As of now, the QUnit assert object is mapped to the OPA assert object. You should now call functions
like strictEqual(), ok(), and equal() on the Opa5.assert object to make sure that the tests still work when QUnit is upgraded to version
2.x.
For more information, see Integration Testing with One Page Acceptance Tests (OPA5).
XSRF token handling in OData Model V2: The XSRF token will now be fetched via an asynchronous HEAD request to improve the performance.
Data state for bindings: Bindings can now have a data state which is accessible via an API.
XML Templating
The new require statement lets template authors specify the modules required for processing the templates. This prevents template view users
from having to require these modules. For more information, see require
The new alias statement in XML templating reduces the typing effort. For more information, see alias.
Extension points can be used in XML templating to extend the standard with custom content. For more information, see Extension Points.
The XMLPreprocessor.IContext interface has been extended to let custom formatter functions access arbitrary path segments in binding
paths. For more information, see Replacement of Bindings.
Annotation Helper
It is now possible to integrate translatable texts into XML templates by using simple bindings to a hard coded model name.
The sap.ui.model.odata.AnnotationHelper is now automatically required in XML templating.
AnnotationHelper supports annotations for an EntitySet.
AnnotationHelper provides a method to create property settings (constant or binding info) from binding expressions.
The documentation now explicitly mentions that xx-bindingSyntax needs to be set to complex to avoid warnings on the console.
For more information, see Annotation Helper.
SAPUI5 Application Index: If you run the index calculation report with the option for repositories based on a defined expiration period, the report also
processes any repositories that have been changed by transports since the last recalculation. For more information, see SAPUI5 Application Index.
Using the SAPUI5 Application Index REST API: To execute the SAPUI5 application index REST API, you now use ICF node
/sap/bc/ui2/app_index instead of ICF node /sap/bc/app_index. For more information, see Securing the SAPUI5 Repository.
Recalculating Meta Data and Resetting Cache Buster Information: To recalculate the meta data and to reset the cache buster information, you can
now add /do-update-meta-data to the URL of your app or component. This replaces /resetcachebuster, which is now deprecated. For more
information, see Cache Buster for SAPUI5 Application Resources.
Object Page:
Four-column layout on XL screens: The object page can have more columns on larger XL screens (that have a width of 1440px or more). This
new feature works out-of-the-box and does not require anything to be set, but note that it only works if you are using blocks as content holders in a
subsection. Now the content in a block can take up to four columns. In addition, the block has an auto setting used to calculate the optimal size
of each block in relation to its surrounding blocks. For more information, see the samples in the Explored app in the Demo Kit.
Two-column layout on L screens: A new property useTwoColumnsForLargeScreen allows overriding the default behavior on large screens
that shows three columns so that two columns are displayed instead.
Responsive prioritization: It is now possible to define priorities for sections and subsections using the importance enumeration
(Low/Medium/High). A responsive behavior for the different screen sizes has been implemented. Also, a new property
showOnlyHighImportance has been added in the ObjectPageLayout control, which alters the behavior of the importance rules so that
regardless of the screen size, only the High importance content of a section or subsection is displayed. In addition, the Expand button has been
implemented to manually expand or collapse the low priority content in sections. The More and Less buttons can be used to manually show or
hide all subsections that are hidden or displayed.
Improved Controls
Field Groups: Controls can now be assigned to logical groups which will trigger an event if this group is left.
Relative Date / Time Formatter: We now provide new options to provide relative date and times (e.g. seconds, minutes etc.)

New Design for Busy Indicator: The visual design of the local and global busy indicator has been updated.
sap.m.ComboBox: Improved rendering performance by internally using sap.m.SelectList instead of sap.m.List.

sap.m.MessagePopover: The text size has been increased on desktop devices. A new showArrow property has been added, which opens the
MessagePopover in Combobox mode, without the arrow.
sap.m.MultiInput: Improved usability by always showing in multi-line mode on phones.
sap.m.MultiInput and MultiComboBox: Added support for copy-and-pasting tokens to Excel.
sap.m.OverflowToolbar:
Prioritization: You can set a priority to each OverflowToolbar item using the new priority property of the LayoutData element. The
priority defines the overflow order of the items when the size of the OverflowToolbar is not enough. The default priority of each
OverflowToolbar item is High. All priorities are accessible through the sap.m.OverflowToolbarPriority type.
Grouping: The new group property of the LayoutData element enables OverflowToolbar items to overflow together even if they are on
different positions. The default value of the property is 0, meaning that the element does not belong to any group. When group elements have
different priorities, the priority of the group is defined by the maximum priority of its elements.
sap.m.SimpleForm: Added support for AriaLabelledBy.
sap.m.Slider: Added option to disable handle tooltip.
sap.m.UploadCollection: In the 'Upload Pending' scenario, you can now select multiple attachments in one step and add these to the upload list.
The control supports canceling the upload of a file of this selection without canceling the other selected files.
sap.m.Wizard:
The new icon property on the WizardStep control enables developers to replace the subsequent step numbering in the progress navigation part
of the Wizard control. In order for the icon to be displayed, each step in the Wizard should have this property defined, otherwise the default
numbering will be displayed.
A branching mode has been implemented to enable users to take multiple paths within a single wizard. Different outcomes and steps are displayed
depending on input from the previous steps. Dashed lines in the wizard progress navigator indicate that all subsequent steps may vary.
A new Summary page has been implemented that is displayed after all steps in a wizard are completed. This enables users to review their input
at a glance and edit it if needed.

sap.suite.ui.commons.ProcessFlow:
Clickable connection labels between process flow nodes have been implemented (ProcessFlowConnectionLabels). If connections are not
unique, you can select a connection by clicking the label. You can hide or unhide these labels.
You can now group nodes that are semantically equal or have some properties in common by using the aggregated node type
sap.suite.ui.commons.ProcessFlowNode. For this reason, the type property has been added to the ProcessFlowNode control.
Possible values are single (default) or aggregated, which can be set by the application. Aggregated nodes are displayed with a shadow
representing the stacked documents.
Smart controls: These controls now support multiple schemas with different namespaces. For more information about smart controls, see the control-
specific information under sap.ui.comp.
sap.ui.comp.smartfield.SmartField: The new property proposedControl is used to make a proposal for a particular control that is to
be used by SmartField. Currently sap.m.ObjectNumber and sap.m.ObjectIdentifier can be selected.
The new event valueListChanged is fired when the model is updated with the selected data after the values have been selected using value
help or type-ahead.
The toggling between edit and display mode is now handled by the editable property instead of the enabled property of the control.
sap.ui.comp.smartfilterbar.SmartFilterBar:
For MultiInput filter fields, the MultiLine mode has been activated to improve usability.
Multi-value and unrestricted Date fields are now supported if the annotation sap:filter-restriction="multi-value" is set for date
properties.
The SmartTable is now easier to use, even without annotations, thanks to these easy-to-use configuration settings:
The new property initiallyVisibleFields is used to specify the columns that are visible when the SmartTable is first started.
The new property requestAtLeastFields is used to specify the fields that should always be requested.
The new PresentationVariant annotation can now be used to do the following:
Change existing behavior to consider LineItem annotation from the Visualizations property
Use RequestAtLeast property to also enable $select for tables that are not of type AnalyticalTable
The LineItem annotation is now a fallback option and used only if no PresentationVariant annotation exists.
The Text annotation is now supported for built-in SmartTable controls (default is descriptionAndId, can be configured using
defaultDropDownDisplayBehaviour custom data)
Several default UI settings have been improved, such as hiding the column visibility menu option from the table header, the right-alignment of date
and time fields, and enabling MultiToggle by default (internally for sap.ui.table.* tables).
Depending on the internal table used, the new noData aggregation can be filled with a string (sap.m.Table and sap.ui.table.Table) or with
sap.ui.core.Control (sap.ui.table.Table only). Providing a control for the noData aggregation allows you to display icons, texts, and
even more complex layouts if no data is available.
The new property ignoreFromPersonalisation can be used to specify the fields that should not be shown in the table personalization dialog.
sap.ui.comp.variants.VariantManagement: If the list of variants contains ten or more items, a simple search is automatically made available
to improve usability.
sap.ui.comp.valuehelpdialog.ValueHelpDialog: The dialog provided by the ValueHelpDialog control now supports smartphone use for
the first time.
sap.ui.layout.DynamicSideContent: The aspect ratio on M breakpoint is changed the side content area now has a 340px fixed width instead of
33% (for better usability on tablet devices and small screens).
Documentation and Demo Kit Improvements

Explored app of the Demo Kit: For better readability of the sample code in the code viewer, line numbering and syntax highlighting have been implemented.
The documentation contains several new helpful chapters. Just to name a few:
App Overview: The Basic Files of Your App
Folder Structure: Where to Put Your Files
App Templates: Kick Start Your App Development
The Device API

Device Adaptation: Using Device Models for Your App
You can now find a list of terms with their definition in the new Glossary.

Tutorials
This new and interactive learning format introduces you to all major development paradigms of SAPUI5. Each tutorial comes with a detailed documentation
and downloadable code in the Explored app in the Demo Kit. The tutorials include a Walkthrough that is starting from a simple 'Hello World' app and going
through the main topics in 35 steps. These topics include expression binding, mock servers, reuse dialogs, unit and integration tests, routing and navigation,
to name just a few. Other tutorials cover topics data binding, navigation and routing, using smart controls. For more information, see Tutorials.
App Templates
Two new app templates are now available for Master-Detail and Worklist apps. They are built using the latest best practises and as such can be used as a
starting point for developing apps with a standard setup. These app templates include basic features that can be extended with custom functionality to build a
full-blown app. You can also use both templates in SAP Web IDE.
Master-Detail: The classic screen layout based on the responsive split container, listing a set of objects and showing details for a selected object. You
can find a demo app for this in the Demo Kit under Demo Apps Master-Detail .
Worklist: This application shows a full-screen layout (in contrast to the Master-Detail layout), displaying a list of work items on the first page and more
details on a subpage. You can find a demo app for this in the Demo Kit under Demo Apps Worklist .
The documentation has been restructured to allow easier navigation through all topics, most of the chapters have been reworked and updated.
The section formerly known as Installing SAPUI5 has been renamed and reworked. It has been updated with new information covering the most
common and recommended development environments. See Development Environment.
Demo Kit Improvements

The API Reference navigation tree in the Demo Kit has been restructured to display a maximum of two levels of nesting.
Contextual filtering has been implemented for the navigation tree of the Demo Kit.
Explored app improvements:
It is now possible to bookmark a specific sample file.
It is now possible to include additional files in the downloadable sample archive, which are not listed as source files.
The source code of the samples files is now displayed with highlighted syntax (using the sap.ui.demokit.CodeViewer control).
New Features
Screen Reader Support: Screen reader support based on the ARIA standard has been added for all sap.m controls, among others. The list of all
relevant libraries as well as important aspects related to control development are available in Screen Reader Support for SAPUI5 Controls. The important
aspects related to app development are available under Accessibility.
Islamic Calendar: The Islamic calendar has been added to the available calendar types and is available for the Calendar control. When, for example,
the current locale is en_US, but the calendar type is set to Islamic (either globally or on a data binding type or in a date formatter), the date May 6,
2015 is formatted as: Raj. 17, 1436 AH.
Switching the SAPUI5 version: You can now switch between existing installations of SAPUI5, for example for debugging purposes or compatibility
checks. If you open the debug mode in the debugging pop-up using Ctrl + Alt + Shift + P or the debugging panel using Ctrl + Alt + Shift + S , you can
choose from all existing installations or specify a custom URL. During the next startup, SAPUI5 will then be loaded from there - without modifying the
app.
Note
This will only work when the SAPUI5 core is loaded with the standard bootstrapping, it is not supported for SAP Fiori launchpad or cases where
customized bootstraps are used.
You can now use the Runtime Adaptation library to allow key users to adapt the user interface of apps during runtime, for example, by adding,
removing, or moving fields and groups. For more information, see UI Adaptation at Runtime.
New Controls
sap.m.semantic.SemanticPage: SemanticPage is an enhanced sap.m.Page control. It provides support for content with semantic meaning (for
example sap.m.semantic.AddAction, sap.m.semantic.EditAction and sap.m.semantic.SortAction) that has predefined visualization
properties and positioning in the page.
The following new controls are based on the SemanticPage control:
sap.m.semantic.MasterPage
sap.m.semantic.DetailPage
sap.m.semantic.FullscreenPage

Figure 1: Semantic Page
sap.m.QuickView: The aim of the QuickView control is to display content in the form of a business card. It uses the
sap.m.ResponsivePopover control, meaning the content occupies the entire screen when using a mobile phone, whereas a popover is displayed on
other devices.
Figure 2: Quick View
sap.m.QuickViewCard: This control represents a card that can be part of sap.m.QuickView and usually contains information about one person or
object. It allows this object to be linked to another object using one of the links in the card.
sap.m.MessageStrip: A simple control for showing messages as text with semantic color, an icon depending on the message type, and optionally a
link (leading to additional information).
sap.ui.layout.DynamicSideContent: The DynamicSideContent control allows additional (side) content to be displayed alongside or below the
main content, within the container in which the control is used. It is intended to be used within the sap.m.Page control but it can exist in any container
control, either taking the whole width of the screen or a large part of it.
sap.m.Wizard: The Wizard control is used to break down complex tasks into smaller steps, for example, creation of a business object or a long
registration form. It is a container control and has WizardSteps as content aggregations.
sap.uxap.ObjectPageLayout: An object page is a concept for a Web page, representing detailed information about a business object. An object
page has a header (sap.uxap.ObjectPageHeaderContent and sap.uxap.ObjectPageHeaderTitle), a navigation bar
(sap.uxap.AnchorBar) and is divided into sections (ObjectPageSection) and subsections (ObjectPageSubSection), each showing some
information about the object in question. For more information, see Object Page Layout.

Improved Features
Annotation Helper now supports a lot of OData constant and dynamic expressions (like Edm:if) in annotation specifications. Furthermore, there are
additional methods for navigating within the meta model (including annotations). Finally, using the AnnotationHelper outside XML templating has
been made easier, by making the second parameter of context-based methods optional. See Annotation Helper.
Asynchronous View Loading: Views can be loaded asynchronously to improve performance. This is done using the loaded() promise in class
sap.ui.core.mvc.View.
Expression Binding now supports arrays (literal and operator), the in-operator, as well as more global symbols. Expression bindings can be used in
composite bindings. As a performance optimization, expression bindings can now also be specified as one-time bindings. See Expression Binding.
The features of the descriptor for applications, components, and libraries (manifest.json) have been extended, for example, with declarative
model creation, see Descriptor for Applications, Components, and Libraries.
XML Templating:
Debug traces have been introduced to XML templating. See Debugging.
The template:repeat statement now supports startIndex and length. Furthermore, the name of the object that is inspected can be used
in the filter condition. See repeat.
Up to now, the name of a fragment that was to be included in an XML view in XML templating needed to be specified as a string constant. Now
you can also specify the name by a binding, see XML Fragments.
OData Model: By default, two-way changes now only send modified properties in a MERGE request. The change event on bindings that informs about
updates is now available.
The OData Meta Model now also exposes most v2 annotations as their corresponding v4 annotations as well. This enables applications to simply react
to the corresponding v4 annotation irrespective of the version actually used for specifying the annotation. The objects in OData Meta Model are arranged
in arrays. Instead of using an index that might not be stable with meta model changes, it is now also possible to use expressions to select an object in
such an array. See Meta Model for OData V2.
Restriction on specific OData types removed: The OData types sap.ui.model.odata.type.Single and
sap.ui.model.odata.type.Double are now writable, just like the other supported OData types in SAPUI5.
sap.ui.model.odata.type.Decimal and sap.ui.model.odata.type.Int64 now support full precision.
Right-to-Left (RTL) Support: Two new API properties have been introduced - textDirection and textAlign. These properties can be used to
ensure proper readability for controls that need to show texts with mixed RTL and LTR directionality. For more information and examples, see API
Properties for Right-to-Left Support in Text-Displaying Controls.
Improved Controls
sap.m.Dialog: Two new public properties have been added: resizable and draggable. The default values of these properties are set to false.
sap.m.MessagePopover: The property markupDescription has been added, which enables the usage of HTML markup as message content.
sap.m.MultiInput and sap.m.MultiComboBox now support copy and paste from Microsoft Excel or Notepad.
sap.m.OverflowToolbar: You can now move more controls to the overflow area.
sap.m.Page: setBusy(true) now covers header and footer correctly, the contentOnlyBusy property has been added to leave them uncovered
(as was previously the case, mistakenly), for example, when the user is expected to keep typing text into a SearchField in the subheader while data
is being updated. The scrollToElement method for scrolling to a specific child element has been added.
sap.m.Panel: The property backgroundDesign has been added.
sap.m.ScrollContainer: The scrollToElement method for scrolling to a specific child element has been added.
sap.m.TextArea: The valueLiveUpdate property has been added. The value property of sap.m.TextArea is not updated on every keystroke,
but only when the user presses Enter or leaves the input field. The change was necessary to fully support the standard data binding with formatters and
types. If you still need an immediate update, you have two options: handle liveChange events or enable the boolean property valueLiveUpdate.
sap.m.UploadCollection:
The numberOfAttachmentsText property for overwriting the toolbar text and the 'Upload Pending' scenario have been implemented.
The numberOfAttachmentsText property enables applications to overwrite the toolbar text. It sets the title text in the toolbar of the list of
attachments. The default value is set to language-dependent Attachments (n) . The getItems().length method lets you also retrieve
the number of attachments in brackets. If a new title is set, the default is deactivated.
The new 'Upload Pending' scenario is provided in addition to the existing UploadCollection scenario (which is also known as an 'Instant
Upload'). In this new scenario, you first select the attachments and then upload them in a separate step. To decide which scenario to use,
you can select the instantUpload property with the respective value:
true for the 'Instant Upload' scenario
false for the 'Upload Pending' scenario
Up to now, only the selection of a single file is supported in this scenario (multiple property = false ). If required, you can select further
files and add them to the list.
After making the selection, you need to trigger the upload of the selected files. To do so, call the upload method of the
sap.m.UploadCollection control, for example by using a pushbutton in the application.
An application can now set file-specific header parameters, for example, file name. For the selection of multiple files in the 'Upload Pending'
scenario, the application can call the upload method to trigger the beforeUploadStarts event for each selected file.
sap.m.UploadCollection.Item: In this class, two new aggregations have been added: attributes (type sap.m.ObjectAttribute) and
statuses (type sap.m.ObjectStatus). These aggregations let you display any number of attributes and statuses for each uploaded item.
The contributor, fileSize, and uploadedDate properties have been deprecated accordingly and will be replaced by the additional attributes.
Note
Please remember that if one of these deprecated properties is filled in addition to the attribute with the same name, two attributes with the same title
are displayed, as these properties are also displayed as attributes. To make sure that the title does not appear twice, check whether one of the
deprecated properties is filled in addition to the attributes.
sap.m.ViewSettingsDialog: You can now define custom tabs with their content added to the dialog, along with three predefined tabs for sorting,
filtering and grouping.
sap.suite.ui.commons.MicroAreaChart: You can now display multiple lines. Each line can have one of the semantic colors or chart colors.
sap.suite.ui.commons.BulletChart: Visual enhancements to the thresholds have been added. Now thresholds are also visible above the actual
bar.

sap.suite.ui.commons.HeaderContainer: You can now display the control in the vertical mode if the view property is set to Vertical.
sap.suite.ui.commons.ComparisonChart: You can now select individual bars.
sap.suite.ui.commons.ColumnMicroChart: You can now select individual columns.
sap.suite.ui.commons.ProcessFlow: For better user guidance, clickable chevrons (arrows) have been introduced in the header. These can be
used in the case of an overflow, for example, when the complete ProcessFlow control cannot be displayed because the visible area is limited. In such
a case, chevrons are added to the header to indicate that some horizontal content is not visible:
For desktops, click these chevrons and move the complete process flow by one lane.
For mobile devices, the chevrons are just indicators, you scroll the ProcessFlow control by touch as before.
Next to the chevrons, the number of lanes that are not visible is displayed. For example, the number 2 next to the right-arrow navigation indicates that
there are two additional lanes not visible in the displayed area.
sap.ui.layout.FixFlex: The minFlexSize property has been added.
sap.ui.table.*: Rendering performance has been improved by 80%.
sap.ui.table.TreeTable now supports sorting operations.
SmartTable now uses the Importance annotation for the LineItems annotation to display columns with priority high on phones, with priority
medium or high on tablets, and with all priorities on the desktop.
When using SmartTable with an internal responsive table, you can now set the new demandPopin property to true. This property renders
columns that exceed the space available on the screen by displaying popins.
SmartTable now checks the custom data section for the columns and reads the columnIndex attribute to determine when the columns that are
defined in the XML view are rendered.
More OData types (provided in sap.ui.model.odata.type) and some additional V4 annotations are now supported by SmartTable.
The usability of the SmartTable control has been improved: There is now only one toolbar shown using a transparent and responsive
OverflowToolbar in case there is no customToolbar (the useOnlyOneSolidToolbar property has therefore been deprecated).
The Org.OData.Measures.V1.Unit annotation to create measure fields on the user interface is now supported.
sap.ui.comp.SmartField:
SmartField now uses the com.sap.vocabularies.Common.v1.Masked annotation to mask the content of its child input field and the
com.sap.vocabularies.ui.v1.MultiLineText annotation to represent a field as a multiline text field.
SmartField now also supports standard links using the new url property.
Until now, when binding a SmartField against the OData service property of type Edm.Boolean, the value was shown as a CheckBox. If a
SmartField is in read-only mode, static texts are now used for visual representation. In addition, a configuration parameter in the SmartField
control can define the properties of the static texts of the CheckBox, such as Yes/No or True/False. For the SmartForm control, the custom data
can be used for this purpose.
sap.ui.comp.smartFilterBar.SmartFilterBar:
More OData types (provided in sap.ui.model.odata.type) and some additional V4 annotations are now supported by SmartFilterBar.
The validation based on types has been enhanced.
The new enableBasicSearch property is available to enable the basic search field (if supported by backend system).
sap.ui.comp.valuehelpdialog.ValueHelpDialog: The dialog provided by the ValueHelpDialog control now offers an improved desktop
version and supports tablet use for the first time. The dialog is now easier to use and more flexible and responsive: For example, when you switch from
landscape to portrait mode on your tablet, the number of rows in the list is automatically adjusted.
To reduce initial load times for OData-model-based user interfaces, the ValueHelp fields in the SmartFilterBar, SmartTable, and SmartField
controls now support partial and lazy loading of the ValueList annotation (if supported by backend system).
Infrastructure on Application Server for ABAP

SAPUI5 Application Index (Changed): You have to define the execution of the report /UI5/APP_INDEX_CALCULATE as a background job for the SAPUI5
application index. This report replaces the report /UI5/UPDATE_CACHEBUSTER used in the user interface add-on 1.0 for SAP NetWeaver. The SAPUI5
application index is an indexing and caching mechanism for information related to SAPUI5 applications, components, and libraries in SAPUI5 repositories on
the SAP NetWeaver Application Server for ABAP and is used by several different services (such as SAP Fiori launchpad and cache buster). Descriptor and
component IDs used in SAPUI5 repositories have to be unique and valid. For more information, see SAPUI5 Application Index.
jQuery Unit Testing Library QUnit Upgraded

The jQuery unit testing library QUnit has been upgraded to version 1.16.0. If you have written QUnit-based unit tests, you may need to adapt these.
SAP Smart Business

As of this version, SAP Smart Business in no longer being updated with the SAPUI5 delivery. SAP Smart Business is now part of the SAP Smart Business
Foundation Component. You can find the documentation for SAP Smart Business on the SAP Help Portal at http://help.sap.com/ssb.

The following sections highlight the main new features and enhancements to SAPUI5. For a complete, detailed list of all new and enhanced functions, see the
New Features
All of these features can be used on their own or in combination with each other. For more information, see the sap.ui.core.mvc.XMLView examples in
the Explored section of the Demo Kit.
Expression Binding: This new feature allows you to use expressions in bindings. This reduces the need to program formatters for views, especially when
using XML templating. For more information, see Expression Binding.

Tip
Example Coding

visible="{= ${status} === 'critical' && ${amount} > 10000 }"

text="{= ${/amount} > 10000 ? ${i18n>/high} : ${i18n>/normal} }"

visible="{= ${/rating}.toUpperCase() === 'VIP' || ${/orderAmount} > 10000 }"

visible={= RegExp('vip', 'i').test(${/rating}) }


text="{= Math.max(${/value1}, ${/value2}, ${/value3}) }"


enabled="{= ${/orderStatus} !== null }"
Composite Types: This new feature allows types to operate on composite bindings. The new Currency type, for example, uses this technology.
Message Handling: New message manager and message model, including a new message popover control.
Standard Margins & Container Paddings: You can now use predefined CSS classes to manage the margins and container paddings in your application.
Take a look at the following documentation and sample links to learn more:
Standard Margin Classes
Samples of standard margin classes in the Explored section of the Demo Kit
Standard Container Padding Classes
Samples of standard container padding classes in the Explored section of the Demo Kit
Routing: The following improvements have been made:
The following new classes have been created for routing:
sap.ui.core.routing.Targets
sap.ui.core.routing.Views
sap.ui.core.routing.Target
sap.m.routing.Targets
sap.ui.core.routing.Router
sap.ui.core.routing.TargetHandler
Views can now be displayed without modifying the hash with Targets.
Multiple views can now be displayed with one route using Targets.
Routing now consists of more modules, for example, the view creation and view placement have been separated from the router.
Some APIs for routes have been renamed and moved to Targets.
Class sap.m.routing.RouteMatchedHandler is now deprecated.
The improved routing is fully backward compatible with routing configurations, meaning you can perform step-by-step migrations.
Clickjacking Protection: In order to protect applications against clickjacking attacks, there are now settings available to control circumstances under which
an SAPUI5 application is allowed to run inside frames. For more information, see Frame Options and Whitelist Service.
Handlebars: The included Handlebars library has been upgraded to version 2.0.
New Controls
sap.m.MessagePage: This control is primarily designed to be used when a page is empty because no data is available, but can be used for other full-page
messages as well.
Figure 1: MessagePage
sap.m.MessagePopover: This control provides a popover containing a summarized list with messages that can be consumed by the user through several
different features like filtering and drilling down to the details.

Figure 2: MessagePopover
sap.m.OverflowToolbar: This control provides you with the option to move buttons that do not fit in the visible area to an overflow menu. The
OverflowToolbar also provides a new layout data called sap.m.OverflowToolbarLayoutData that can alter the default behavior of controls by
forcing them to always stay in the overflow menu, or to never move in there. Currently, only controls of type sap.m.Button can be moved to the overflow
menu.
Figure 3: OverflowToolbar
sap.m.Title: This new control is a simple line of text which should be used for section headings. It provides semantic information about the level in the
page structure of the section the heading belongs to, and is needed for usability purposes.
sap.suite.ui.commons.HarveyBallMicroChart: This new control allows you to display a fraction value versus total as a micro chart. You can set
one of the predefined sizes and also optionally set the width of the control. You can use either semantic or palette colors for the fraction.
sap.suite.ui.commons.DeltaMicroChart: This new control allows you to display two values as well as an automatically calculated delta as a micro
chart. You can set one of the predefined sizes and also optionally set the width of the control. Semantic colors can be applied to the delta. You can define
custom labels for the values in the chart.
sap.ui.comp.navpopover.SmartLink: This new control provides a popover with navigation links to related applications, for example, more detailed
information about customer data.
sap.ui.comp.smartform.SmartForm: This new control makes it possible to render a form using OData metadata annotations. Depending on user
authorizations, the form enables users to switch from display to edit mode, add and group fields, rename field labels, and implement a user input check, for
example.
SAPUI5 Flexibility Services have been enhanced with features that allow you to adapt screens for multiple users using the SmartForm control, for example,
by adding and grouping fields.
sap.ui.comp.smartfield.SmartField: This new control offers a wrapper for other controls using OData metadata to determine which control has to be
instantiated.
Control Improvements
sap.m.Column: A new WithoutHeader popin display option has been added, which allows you to hide headers if needed.
sap.m.MessageBox: New options and features added, such as initialFocus, textDirection, verticalScrolling, horizontalScrolling,
and details.
sap.m.MultiInput: A new enableMultiLineMode API has been introduced, which displays the MultiInput control in multi-line display mode when
set to true.
sap.m.ObjectHeader: The responsive ObjectHeader has a new design depending on the device, which is based on media breakpoints. In the new
design, the sap.m.IconTabBar control is always displayed below the ObjectHeader.

sap.m.ObjectListItem: A dedicated icon is now available to indicate whether the object is locked.
sap.m.SegmentedButton: Enhanced binding of the selected button (new items aggregation).
sap.suite.ui.commons.ColumnMicroChart: You are now able to define labels and show them using semantic colors in the corners of the chart.
sap.ui.unified.Calendar: A multi-calendar view is now available, allowing you to place several calendars within a single view to support date picks
across months without navigation.
sap.ui.layout.form.SimpleForm: A new width property has now been added.
sap.ui.unified.FileUploader: Performing an upload with multiple: true and useMultipart: false is handled by several requests, one for
each file.
sap.ui.table.TreeTable: New paging support with lazy loading of tree nodes using OData hierarchy annotations and new auto expand feature which
expands the tree to a specified level. Export to Microsoft Excel also enabled.
sap.ui.table.Table: An auto BusyIndicator has now been added.
sap.suite.ui.commons.ProcessFlow: Mobile enablement has now been implemented for this control. As part of this enablement, the responsiveness
has been adapted. The initial zoom level is now responsive and depends on the container size of the ProcessFlow control.
sap.ui.comp.smarttable.SmartTable: The SmartTable control now supports editing scenarios.
P13nColumnsPanel: The new visibleItemsTreshold property in the P13nColumnsPanel as part of the P13nDialog control limits the number of
table columns selected by the end user during table personalization to avoid slow performance.
SAPUI5 Tools
The HTTP handler for SAPUI5 applications now supports cache busting at application or component level (report /UI5/APP_INDEX_CALCULATE needs to be
scheduled). The SAP Fiori launchpad uses this cache busting to ensure that the users do not have to clear the browser cache manually after application
updates on the server. For more information, see SAP Library for User Interface Add-On 1.0 for SAP NetWeaver on SAP Help Portal at
http://help.sap.com/nw-uiaddon. Under Application Help, open SAP Library and search for Cache Buster for SAP Fiori.
To study the coding and the effect of cache busting for application resources, now the sample application SIMPLETEST is available.
Documentation of Coding Issues to Avoid: This new documentation section lists some of the most important issues that must be avoided when creating
applications using SAPUI5 (see Coding Issues to Avoid).
Demo Kit: The following improvements have been made to the Explored section:
You can now toggle the samples to full-screen display.
You can now open the samples in a new browser tab.
Most of the samples can now be downloaded as standalone, fully runnable web applications.

The following sections highlight the main new features and enhancements to SAPUI5. For a complete, detailed list of all new and enhanced functions, see the
Main New Features

New OData Model Implementation: Features greatly improved two-way binding and $batch support, as well as improved performance overall through reduced
and more asynchronous requests.
Support for Windows Phone (IE11 in Windows Phone 8.1 update 1): This support is valid for the following libraries (those supporting mobile devices):
sap.m, sap.ui.core, sap.ui.layout and sap.ui.unified.
Usability Enhancements - Keyboard Shortcuts: Version 1.26 contains enhanced usability features, including new keyboard shortcuts for SAPUI5 controls.
Usability Enhancements - High Contrast Black: Version 1.26 also includes High Contrast Black (HCB) theme support for the sap.m library.
Fast Keyboard Navigation: The new fast keyboard navigation allows you to navigate quickly between groups using F6. For more information, see Defining
Groups for Fast Navigation (F6).
Mobile Diagnostics: We have improved the structure of the mobile diagnostics dialog and added a new function for end-to-end (E2E) tracing. You can now
open the dialog with the following touch combination: press two fingers on a non-interactive screen area (for example, a blank area) for at least 3 seconds, then
tap with a third finger while still holding the other two on the screen. For more information, see Technical Information Dialog.
jQuery 1.11.1: This version of jQuery is now used by default.
Extensibility: ExtensionPoints are now also offered in JSViews and controls can be hidden in all View types.
OPA (One Page Acceptance) Tests: The OPA tests have been improved. There is now a new way to structure your OPA tests: If you have multiple pages or
UI areas that have several operations, you should place them as reuse functionality in page objects to make your OPA tests easier to maintain.
Visible Attribute: A visible attribute is now available for all controls, as they now inherit this property from the sap.ui.core.Control class.
SAPUI5 Flexibility Services: These services offer a multiple-layer approach and provide various features with regards to configuration and personalization
functions for your SAPUI5 applications, such as variant management and personalized table settings.
New Node Type for sap.suite.ui.commons.ProcessFlow: The node type Planned with Issue is now available for
sap.suite.ui.commons.ProcessFlow, meaning you can now choose between using a node Planned without a status, or with the status Planned with
Issue .
Main New Controls

sap.ui.layout.FixFlex: This new control addresses the common layout use case where one part of the UI has a certain size (which may be set, or may
be defined by the content size) and the other part of the UI should use all of the remaining space (horizontally and vertically). It also supports Internet Explorer
9 (which is not supported by the more powerful sap.m.Flexbox control).
sap.m.RadioButtonGroup: This new control improves the use of layouting, keyboard navigation and data binding for radio buttons.
sap.m.SelectList:
sap.m.UploadCollection: This new control is a list control for attachment management. It is based on the sap.ui.unified.FileUploader control
and allows you to upload, edit or delete attachments.
Smart Table: This new control is used to create various types of tables based on OData metadata and for personalized table settings.
P13nDialog: This new control provides a dialog for personalizing tables.
1.2 Read Me First

Before you start using SAPUI5, please read the important information in the section. Here you read everything you need to know about supported library
combinations, the supported browsers and platforms, and so on.
In this section:
SAPUI5 vs. OpenUI5
With SAPUI5 and OpenUI5 we provide two deliveries of our UI development toolkit. Both are very closely related, but have their differences.
Versioning of SAPUI5
As of SAPUI5 1.6 there is a close coupling of SAPUI5 core/runtime and SAPUI5 tools: It is required that within a running system both have the same
version, that is, have the same major and minor version.
Upgrading
The following sections describe what you have to consider when upgrading to a new version of SAPUI5.
Compatibility Rules
The following sections describe what SAP can change in major, minor, and patch releases. Always consider these rules when developing apps, features, or
controls with or for SAPUI5.
Supported Library Combinations
SAPUI5 provides a set of JavaScript and CSS libraries, which can be combined in an application using the combinations that are supported.
As SAPUI5 evolves over time, some of the UI controls are replaced by others, or their concepts abandoned entirely. This chapter gives an overview on
theme and library level of the most important deprecations. Individual control deprecations and more information about the controls replacing them can be
found in the API reference within the Demo Kit.
Browser and Platform Support
This sections describes which browsers and platforms are supported by the various SAPUI5 libraries.
Demo Kit and Platform-Specific Documentation
The SAPUI5 documentation is included in the Demo Kit. The Demo Kit also provides you with technical documentation and samples. There are also
platform-specific variants of the documentation available at other locations.
Development Environment
This part of the documentation gives you guidance on the most common and recommended use cases of the installation, configuration and setup of the UI
development toolkit for HTML5 (SAPUI5) development environment.
SAPUI5 vs. OpenUI5

With SAPUI5 and OpenUI5 we provide two deliveries of our UI development toolkit. Both are very closely related, but have their differences.
Licenses
The main difference is the license.
OpenUI5 is Open Source, free to use, released under the Apache 2.0 license. Since we also use many Open Source libraries, we try to return the favor and
also benefit from the experience and knowledge of developers all over the world.
SAPUI5 is not a separate SAP product with a separate license. It's integrated in the following products:
SAP HANA
SAP HANA Cloud Platform
SAP NetWeaver 7.4 or higher (included in the UI technologies (SAP_UI) component)
User interface add-on for SAP NetWeaver for SAP NetWeaver Application Server 7.3x
Content
The easiest way to get an overview of which libraries are delivered is to have a look at the API Reference of the each Demo Kit. You'll see that the list of
libraries in SAPUI5 is much longer... which in no way means that OpenUI5 provides just a very limited scope!
Most importantly, the core containing all central functionality and the most commonly used control libraries is identical in both deliveries. (For example,
sap.m, sap.ui.layout, sap.ui.unified, and the more desktop-focused libraries sap.ui.commons, sap.ui.ux3.)
So OpenUI5 also gives you all the important features needed to build feature-rich Web applications.
The additional libraries in SAPUI5 include more controls on top, like charts, and SAPUI5 also lets you use 'smart controls', for example, which are controls that
are automatically configured by OData annotations from the back end. The exact feature range of SAPUI5 also depends on the platform you're using. For
example, you can only use the ABAP repository with SAP NetWeaver and not on SAP HANA Cloud Platform.
Contributing to OpenUI5
OpenUI5 is Open Source, and is available on GitHub .
If you find a bug or have an idea for a new feature - just go ahead and propose a GitHub issue or a change. But before you do so, please just read our

guidelines first: Contributing to OpenUI5 .
Resources
For the OpenUI5 version, visit http://openui5.org/ where you can download the runtime and the Demo Kit (SDK) at http://openui5.org/download.html.
For the SAPUI5 resources, check your platform installation.
Both resources are also available online via the content delivery network provider Akamai at https://openui5.hana.ondemand.com/ and
https://sapui5.hana.ondemand.com/
Compatibility of OpenUI5 and SAPUI5

Technically, you can switch between OpenUI5 and SAPUI5 (providing you have the respective license), e.g. if you want to use the SAPUI5-specific features.
Just check first which SAPUI5 version you need, because the version numbering is not 100% the same. The OpenUI5 version number must match the Core
Version number of the SAPUI5 version. You can find this information in the technical info dialog ( Ctrl + Alt + Shift + P ).
If you're using the content delivery network, you can simply replace the bootstrapping reference to
https://openui5.hana.ondemand.com/<1.xx.yy>/ with a reference to https://sapui5.hana.ondemand.com/<1.xx.zz>/. For more
information, see Variant for Bootstrapping from Content Delivery Network.
For all other cases, replace the runtime. Since the technical names (of controls, libraries, etc.) and APIs are the same in both OpenUI5 and SAPUI5, the code
will still work and you can start enhancing it directly.
As of SAPUI5 1.6 there is a close coupling of SAPUI5 core/runtime and SAPUI5 tools: It is required that within a running system both have the same version,
that is, have the same major and minor version.
For example, SAPUI5 core/runtime 1.x.1 works together with SAPUI5 tools 1.x.2, but not with SAPUI5 tools 1.y. For a future release it is planned to have a
more loose coupling here with regards to the minor and micro version.
Note
As of SAPUI5 1.6 we can only support customers who follow this rule in their system landscapes.
Versioning Scheme
SAPUI5 uses a 3-digit version identifier, for example 1.26.4. These digits have the following meaning:
The first digit (1) specifies the major version number.
The second digit (26) specifies the minor version number.
The third digit (4) specifies the patch version number.
The version number for each new SAPUI5 release contains a major and minor version number. The patch version number is only used to identify patches
within a release.
Multi-Version Support for SAP HANA Cloud Platform

If you are using SAPUI5 or OpenUI5 from SAP HANA Cloud Platform, you have the option to switch to a different version as described in Variant for
Bootstrapping from Content Delivery Network.
Check the available versions with respective maintenance status at https://sapui5.hana.ondemand.com/versionoverview.html and
https://openui5.hana.ondemand.com/versionoverview.html.
The SAPUI5 maintenance strategy for SAP HANA Cloud Platform is available in this document.
1.2.3 Upgrading
The following sections describe what you have to consider when upgrading to a new version of SAPUI5.
In this section:
When upgrading to the current SAPUI5 version from a version below 1.38 (released in June 2016), check whether the changes listed below influence your
apps.
When upgrading to the current SAPUI5 version from a version below 1.30 (released in September 2015), check whether the changes listed below influence
your apps.
When upgrading to the current SAPUI5 version from a version below 1.20 (released in April 2014), check whether the changes listed below influence your
apps.

When upgrading to the current SAPUI5 version from a version below 1.38 (released in June 2016), check whether the changes listed below influence your
apps.
With this SAPUI5 version, jQuery has been upgraded to version 2.2.3.
This upgrade may impact your SAPUI5 apps. The following sections give an overview of our findings and how to deal with them.

Note
If you use additional open-source libraries that depend on jQuery, check whether they need to be upgraded as well.
jQuery.Event
Problem
jQuery removed some robustness checks in its event handling code. Without these checks, the jQuery.trigger function must only be called with events
that either have no originalEvent property or where the originalEvent has all methods that window.Event implements (especially
preventDefault, stopPropagation and stopImmediatePropagation).
When a jQuery.Event is constructed with an object literal (properties) or when originalEvent is set to some object after construction, this constraint
is not fulfilled. Unfortunately, many SAPUI5 unit tests used this approach to simulate mouse or key events.
Solution
For each code that creates events, you have to apply the following fix:
The module QUnitUtils now rewrites the jQuery.Event constructor so that any given object literal is enriched with the missing methods. Most SAPUI5
unit tests include the QUnitUtils module early, which then fixes the issue.
Application code that needs to simulate an event, either should omit the originalEvent or use Event.create to create a native event and only then
create a jQuery.Event.
jQuery.fn.position
Problem
jQuery.fn.position now takes the scroll positions of the parent element into account. This change was recoginzed as incompatible by the jQuery team
and reverted with version 2.2.1.
Solution
Nothing, this is automatically fixed.
jQuery.now
Problem
jQuery.now is now set to Date.now for all browsers. But as the jQuery property represents a separate reference to that function, it is not touched by code
that modifies Date.now, especially not by Sinon fake timers. Therefore Sinon fake timers don't work with jQuery 2.2 if Sinon is started after jQuery.
Solution
As a workaround, QUnitUtils redefines jQuery.now so that it delegates to the current Date.now. This will then use any installed fake timer.
:visible selector
Problem
Somewhere between jQuery 1.11.1 and 2.2.0, the behavior of the :visible selector has changed. For empty inline elements (for example, a span with no
text), the selector now reports :visible = true whereas jQuery 1.1.1 reported it as hidden. There was only one functionality in the sap.ui.dt library
where this change in behavior caused problems.
Solution
Instead of using :visible, that functionality now uses its own implementation similar to jQuery 1.11.1.
Sizzle attribute selector ([name=value])

Problem
In Microsoft Internet Explorer, the attribute selector no longer works when the attribute value is unquoted and starts with a hash (#). This is the case when
hash-name-references are searched for, like with the usemap attribute of the IMG element.
Solution
Use quotes ("") for attribute values in those cases.
jQuery.isPlainObject
Problem
jQuery 2.2.0 simplified the implementation of jQuery.isPlainObject. As a side-effect, objects with a constructor property with a non-function value
(like a string value) caused a runtime error when jQuery.isPlainObject was applied.
Solution
This issue is fixed with jQuery 2.2.2.
Descriptor for Applications, Components, and Libraries

If you want to add new attributes of a descriptor version higher than V2 (SAPUI5 1.30) to your existing manifest.json file, see Migration Information for
Upgrading the Descriptor File.

When upgrading to the current SAPUI5 version from a version below 1.30 (released in September 2015), check whether the changes listed below influence
your apps.
This SAPUI5 version also contains the following upgrades:
jQuery upgraded from version 1.11.1 to version 2.1.4
QUnit upgraded from version 1.10.0 to version 1.16.10
Note
jQuery: Dependency onjQuery Code that is Specific to Microsoft Internet Explorer 8.0 (IE8)
SAPUI5 contained some code that referenced IE8-specific members of the jQuery API (like jquery.css.Hooks.opacity.set). This code has been
removed.
jQuery: Error Handling in Synchronous XHR Calls

jQuery 2.x changed the way how XMLHttpRequests (XHR) inside the jQuery.ajax call. One side-effect of this refactoring is that errors thrown in the
success or error callbacks of jQuery.ajax are no longer visible for a caller of synchronous jQuery.ajax() calls. They are caught by the XHR event
hooks (like onload, onerror) that jQuery uses now. Only try/catch statements inside the callbacks will catch such exceptions, but not try/catch
statements outside the callbacks.
Example
window.onerror = function(e) {
alert("global error handler caught " + e);
return true;
}
try {
jQuery.ajax({
url: './nonexisting.json',
async: false,
dataType: 'json',
success: function() {
console.info("success");
},
error: function(xhr,error,status) {
^// this error will not be caught by the try/catch below, only by the global error handler above
throw new Error("error fetching resource with jQuery " + jQuery.fn.jquery + ": " + xhr.status + " " + status);
}
});
} catch (e) {
// never reached with jQuery 2, but worked with jQuery 1.11.1
alert("try-catch caught " + e.message);
}
jQuery: Incompatibility of jQuery.animate and sinon.fakeTimers

As jQuery 2.x only runs on browsers that support ECMAScript 5, the implementation of some helper methods have been changed and now rely on
ECMAScript 5 features. One of these methods is jQuery.now which now is implemented as follows:
// not the exact code from jQuery, but same effect
jQuery.now = Date.now;
sinon.js when instructed to fakeTimers however replaces Date.now with an own version that listens to sinon.clock.tick().
This means that when jQuery is loaded before Sinon, it will keep a reference to the original Date.now function in the jQuery.now API. Therefore any code
that uses jQuery.now() will not work with Sinon fake timers, or more specific, it will not react on e.g. sinon.timer.tick(xyz).
This especially affects jQuery animations and sap.ui.core.Popup that uses these animations. They won't work with sinon.fakeTimers out of the box.
To solve this, you can stub the jQuery.now() function when Sinon is used. Stub it in a way that the mocked version of Date.now is called.
QUnit: DOM Prerequisites

Problem
QUnit changed its requirements regarding the test page. While earlier versions accepted fine-grained DOM sections for header, banner, userAgent, or
tests, QUnit 1.16.0 only expects (and accepts) a single DOM hook called qunit. All details inside that DOM are managed by QUnit itself. If no DOM
element with ID qunit exists, the initialization of QUnit is skipped and no tests are executed.
Solution
As short-term solution, you can use module sap/ui/test/qunit-junit.js to wrap an existing 'qunit-header' in case id='qunit' is missing.
As long-term solution, you have to migrate test pages to the suggested page content.

QUnit: start() and stop() Methods
Problem
When methods start() and stop() are called either unbalanced (more start() than stop() calls) or when they are called outside of a test context, the
test fails. Before, this was already regarded as wrong usage in earlier QUnit versions, but tests did not fail.
For example, test cases fail that unnecessarily use stop() before defining an asynchronous test with {asyncTests();.
Solution
Remove unnecessary start() and stop() calls.
QUnit: Removal of Deprecated Methods and 'window' Properties

Problem
QUnit 1.16.0 removed some deprecated methods and reduced the number of globally visible properties.
QUnit.raises() and window.raises no longer exist; use QUnit.throws instead.
Module sap/ui/test/QUnitUtils.js restores the old name and exports it to the window object as well. window.assert does no longer expose
the value of QUnit.assert. Instead, each test function receives a contextualized instance of Assert which should be used to code assertions like
this:
test("my sophisticated test", function(assert) {
assert.equal("x", "u", "'x' should be an 'u'");
}
Solution
As short-term solution, you can use module sap/ui/test/qunit-junit.js to restore the old behavior.
As long-term solution, migrate to the suggested QUnit APIs.
QUnit: Assertion Logging

Problem
While tests are executed, QUnit collects the result and message of each assertion and displays them to the end user. In QUnit 1.10.0 the report was created
after test execution, in QUnit 1.16.0, the QUnit DOM is updated 'on the fly' while the test is running.
This means that tests that open a popup with a followOf element or, for example, use CLOSE_ON_SCROLL might run into unexpected contexts as the
fixture DOM might move due to the live-logging.
Solution
The live-update cannot be suppressed. As a workaround, you can move the UIArea for the fixtureto the top of the <body> and move the QUnit reporting
section (<div id='qunit'></div>) after that. Thereby, the DOM update does no longer modify the position of fixture DOM.
Related Information
Cookbook for QUnit on http://qunitjs.com/

When upgrading to the current SAPUI5 version from a version below 1.20 (released in April 2014), check whether the changes listed below influence your
apps.
This SAPUI5 version also contains the following upgrades:
jQuery upgraded to version 1.10.2
QUnit upgraded to version 1.10.4
Note
Upgrade to jQuery version 1.10.2

This upgrade requires changes to SAPUI5 controls and may also influence other controls or the application. For more information about the jQuery upgrade,
see the jQuery Upgrade Guide. The following list gives an overview of the changes that affect SAPUI5.
Findings
Setting height or width of a JQuery object
When setting the height or width of an object via jQuery(...).height("1px") and the object used the CSS-property box-sizing, the
height of the box instead of the content was changed. As of jQuery 1.8.0, the function changes the content height regardless of the box-sizing
property.
For more information and recommendations, see the jQuery API documentation on http://api.jquery.com .
jQuery().data("events")
jQuery(...).data("events") has been removed with jQuery 1.9. An alternative is now available and part of the QUnitUtils:
jQuery#_sapTest_dataEvents().
strictEqual in QUnit tests
Do not compare jQuery(...).attr("tabindex") with strictEqual or ===. As an alternative, use string values or prop("tabindex")
which returns a parsed value.
font-weight: "normal"

jQuery 1.10 converts font-weight: "normal" to the value 400. The workaround jQuery#_sapTest_cssFontWeight() is provided in
QUnitUtils that hides the differences between browser and jQuery.
Check for jQuery version
To fix issues for a newer or different jQuery version, you can use jQuery.sap.Version(jQuery.fn.jquery).toString() or
jQuery.sap.Version(jQuery.fn.jquery).getMajor() to check the version. You use this core function to check the major, minor, patch and
all appending stuff of the version.
Deprecated and removed functions
Common
Check for functions that have been deprecated in jQuery versions 1.7, 1.8, or 1.9 and may have been removed in jQuery 1.10. See the
corresponding jQuery documentation.
.live()
This function has been set as deprecated in jQuery version 1.7 and was removed in jQuery version 1.9. For recommendations how to replace the
.live() function, see the respective jQery documentation.
JQuery UI Upgrade to 1.10.4

jQuery UI version 1.10.4 contains incompatible changes to jQuery UI version 1.8.23. For more information, see the jQuery UI 1.9 Upgrade Guide and the
jQuery UI 1.10 Upgrade Guide.
A major incompatible change is in jQuery.ui.position, where the offset property has been removed. SAPUI5 runtime adopted this change, for example in
Popup, but applications may need to adopt their logic too.
Also, the file names for jQuery UI effects have changed. Applications using the jQuery UI effects may also have to adopt their logic. In IE8 and jQuery version
<1.8, the detection whether the new jQueryUi logic is active or not fails. This may be due to interaction issues between jQuery UI version 1.10 and jQuery
version 1.7. In this case, the new jQuery UI position logic is used: Applications that still want to use jQuery version 1.7.1 and jQuery UI version 1.8 or older
have to load the jQueryUI core and not only the position module.
1.2.4 Compatibility Rules

The following sections describe what SAP can change in major, minor, and patch releases. Always consider these rules when developing apps, features, or
controls with or for SAPUI5.
Caution
As an app developer, never do the following:
Never manipulate HTML/CSS via JavaScript (domRef.className = "someCSSClass";) or directly via CSS, for example. Always follow our
recommendations under CSS Styling Issues.
Never use or override "private" functions that are not part of the API Reference . Private functions are typically (but not always) prefixed with a
preceding "_". Always double-check the API Reference, private functions are not listed there.
API Evolution
Unless otherwise mentioned, the word "API" in this section refers to "public API", meaning functions, classes, namespaces, controls along with their declared
properties, aggregations, and so on. The sole definition of the public API is the , which is included in the SAPUI5 Demo Kit. Features that are not mentioned
there are not part of the API.
The following rules apply for introducing new APIs or making incompatible changes to existing APIs:
Major release (x.yy.zz): A new major version can introduce new APIs or make incompatible changes to existing APIs.
Minor release (x.yy.zz): A new minor version can introduce new APIs but must not contain incompatible changes to any APIs.
Patch release (x.yy.zz): A new patch version only contains fixes to the existing implementation, but does not usually contain new features or incompatible
API changes.
Note
Exceptions to these rules are possible, but only in very urgent cases such as security issues. Such exceptions are documented in the Change Log in the
Demo Kit.
Compatible Changes
The following changes to existing APIs are compatible and can be done anytime:
Adding new libraries, controls, classes, properties, functions, or namespaces
Generalizing properties, that is moving properties up in the inheritance hierarchy
Adding new values to enumeration types; this means that when dealing with enum properties, always be prepared to accept new values, for example, by
implementing a "default" or "otherwise" path when reacting on enum values.
Incompatible Changes
The following is not part of the public API and may change in patch and minor releases:
Open source libraries (see Third-Party Open Source Libraries)
Log messages
The following changes to existing APIs are incompatible, but can be done in a new major release:
Renaming an API (library, namespace, function, property, control, events, and so on)
Removing support for parameters
Removing support for configuration entries

Reducing the visibility of an API; this does not break JavaScript applications, but changes the contract
Removing or reordering parameters in an API signature
Reducing the accepted value range, for example, parameter of a function
Broadening the value range of a return value (or property). Exception: enumerations
Moving JavaScript artifacts (namespaces, functions, classes) between modules
Replacing asserts with precondition checks
Moving properties (and so on) down in the inheritance hierarchy
Changing the name of enum values
Changing defaults (properties, function parameters)
Renaming or removing files
Inheritance
Inheriting from SAPUI5 objects (e.g. by calling sap.ui.extend on an existing control to add custom functionality) may endanger the updatability of your
code.
When overriding an SAPUI5 lifecycle method (such as init, exit, onBeforeRendering, and onAfterRendering), you must make sure that the super
class implementation is called, for example like this:
MyClass.prototype.onAfterRendering = function() {
SuperClass.prototype.onAfterRendering.apply(this);
// do your additional stuff AFTER calling super class

}
SAP might add, remove, or change the internal implementation of the parent class at any time. Especially, you should not rely on the following functionality:
Internal structures and methods that are not part of the public API
Any internal logic and behavior of the object that is not reflected in the public API
All rendering functionality of a control, including the HTML structure and CSS classes
Naming collisions with SAPUI5 structures and methods. SAPUI5 might introduce new API or internal structures at a later point in time that collide with
your implementation. To avoid collisions, a custom prefix may be applied. Don't use namespaces starting with sap.m.* or sap.ui.* in your app.
We recommend that you test inherited classes very carefully after updating SAPUI5 to make sure that the extended functionality is still working as expected.
Deprecation
If possible and appropriate, we mark old artifacts as deprecated and create new artifacts, instead of making incompatible changes. A deprecation comment in
the corresponding API documentation, and perhaps also a log entry in the implementation, explain why and when an artifact has been deprecated and include
tips on how to achieve the same results without using deprecated functionality.
Experimental API
Some features or controls delivered with the current SAPUI5 version are flagged as "experimental". These experimental features and controls are not part of
the released scope of the delivered SAPUI5 version. Do not use experimental features or controls in a productive environment, or with data that has not been
sufficiently backed up.
Experimental features and controls can be changed or deleted at any time without notice, and without a formal deprecation process. They may also be
incompatible to changes provided in an upgrade.
Third-Party Open Source Libraries

SAPUI5 contains and uses several third-party open source libraries, such as jQuery . These libraries can also be used by applications and/or custom control
libraries, but the SAPUI5 compatibility rules described in this document do not apply to these third-party libraries.
If you want to use the third-party open source libraries included in SAPUI5, note the following restrictions:
SAP decides which versions and modules of the used libraries are provided.
SAP can upgrade to a higher version of the used libraries even within a patch release.
If we change to a new default version of a library, we document our findings that might have an effect on SAPUI5 apps (see Upgrading). Make sure that
you adapt your code if necessary!
For important reasons such as security, SAPUI5 can stop providing a library at any time.
The third-party libraries are provided "as is". Extensions, adaptations, and support are not performed or provided by SAP.
Note
You are only allowed to use closed source libraries for the SAPUI5 controls for which they are intended.
For a list of the third-party open source software used in SAPUI5, see the Included Third-Party Software link in the About dialog in the Demo Kit.
Related Information
1.2.5 Supported Library Combinations

SAPUI5 provides a set of JavaScript and CSS libraries, which can be combined in an application using the combinations that are supported.
There are two sets of possible library combinations, which are best described using the diagram below. Any of the libraries listed on the lefthand side can be
used with those listed in the middle, and any of the libraries listed on the righthand side can be used with the ones listed in the middle. The libraries listed on
the lefthand side cannot be used in combination with the libraries listed on the right, and vice versa:

Related Information
1.2.6 Deprecated Themes and Libraries

As SAPUI5 evolves over time, some of the UI controls are replaced by others, or their concepts abandoned entirely. This chapter gives an overview on theme
and library level of the most important deprecations. Individual control deprecations and more information about the controls replacing them can be found in the
API reference within the Demo Kit.
Deprecated Themes
sap_ux
The sap_ux theme is deprecated as of version 1.38. This was one of the very first SAPUI5 themes and is only implemented by a small subset of the
sap.ui.commons and sap.ui.ux3 controls, which are also deprecated.
sap_platinum
The sap_platinum theme is deprecated as of version 1.38. This was one of the very first SAPUI5 themes and is only implemented by a small subset of
the sap.ui.commons and sap.ui.ux3 controls, which are also deprecated.
sap_goldreflection
The sap_goldreflection theme is deprecated as of version 1.38. This was one of the first SAPUI5 themes and is only implemented by the
sap.ui.commons and sap.ui.ux3 controls, which are also deprecated.
Deprecated Libraries
sap.ui.commons
The sap.ui.commons library is deprecated as of version 1.38.
sap.ui.commons was available from the very beginning of SAPUI5. It contains a large number of basic UI controls like buttons, input fields and
dropdowns. With version 1.16, the sap.m library was introduced. It contains semantically identical controls (button, input and select) that, at that time, were
only supported on mobile platforms. In later versions, sap.m was extended to support desktop platforms as well. For more information about this, see sap.m,
sap.ui.table, sap.uxap, sap.tnt. The sap.m controls were bigger in size to support mobile displays that require a larger touch area. The Compact Content
Density feature explained under Content Densities was then added to SAPUI5, allowing you to display a control in a more compact screen size. Today,
applications should be built one single time using sap.m (and other libraries) and their content density switched at runtime depending on the environment. As
such, the redundant library sap.ui.commons should no longer be used.
Some of the controls in sap.ui.commons.layout have been replaced by the new dedicated layout library called sap.ui.layout , which runs on the
same platforms as sap.m .
Some of the old controls have been made available again through the non-deprecated sap.ui.unified library (e.g. FileUploader, Menu), which runs on the
same platforms as sap.m .
Some concepts such as Tree, Accordion and Row Repeater have been abandoned completely.
Note
Should you decide to ignore the deprecation and continue using sap.ui.commons , you should at least use the sap_bluecrystal theme and not the
sap_ux , sap_platinum and sap_goldreflection themes, which are also deprecated, as this is more favorable than using a combination of
library and theme that are both deprecated.
sap.ui.ux3
The sap.ui.ux3 library is deprecated as of version 1.38.
This library contains more complex UI controls that were based on sap.ui.commons along the UX3 design approach. The sap.m library - successor to
sap.ui.commons - implements SAPs new SAP Fiori design [http://experience.sap.com/fiori-design/], which supersedes UX3. As such, the sap.ui.ux3
library is also deprecated. Some of the UX3 concepts are reflected in SAP Fiori, some are abandoned, as outlined in the following table:
Concept What's Happened?
Feeds Replaced by sap.m (sap.m.Feed*).
Notification Bar Replaced by sap.m (sap.m.MessagePopover and sap.m.semantic*).
Thing Inspector Indirectly replaced by a different design for displaying object data.

Shell Partially replaced by sap.ui.unified.Shell.
Data Set Not part of SAP Fiori.
Exact Not directly part of SAP Fiori. Use sap.ui.comp.FilterBar or

sap.m.IconTabBar for filtering.
Quick Views Concept abandoned as the concept of hovering with the mouse pointer over a
control does not exist on mobile devices.
For more information about the SAP Fiori design, see the SAP Fiori Design Guidelines.
Note
Should you decide to ignore the deprecation and continue using sap.ui.ux3 , you should at least use the sap_bluecrystal theme and not the
sap_ux , sap_platinum and sap_goldreflection themes, which are also deprecated, as this is more favorable than using a combination of
library and theme that are both deprecated.
sap.ca
The sap.ca library is deprecated as of version 1.22.
This library contains a mixture of controls for various use cases. Some were replaced by sap.m (e.g. DatePicker, Message) and some were discontinued
without being replaced (such as Hierarchy or OverflowContainer).
sap.me
The sap.me library is deprecated as of version 1.34.
The main feature within the sap.me library are the calendar controls. You find replacement controls in the sap.ui.unified library covering most but not
all features of the sap.me calendars.
sap.makit
The sap.makit library is deprecated as of version 1.38.
The sap.makit library contains a few chart controls that only support mobile platforms and do not support accessibility measures. This library is replaced
by sap.viz .
Related Information
Supported Library Combinations
1.2.7 Browser and Platform Support

This sections describes which browsers and platforms are supported by the various SAPUI5 libraries.
Caution
The single source of truth about supported browsers and platforms is the Product Availability Matrix (PAM) that you can find at
https://support.sap.com/pam. SAPUI5 is not a product of its own, so please check the PAM for the product you're using SAPUI5 with. For more
information, see SAP Note 1716423 .
The following sections only contain additional information on restrictions and platform support information for specific SAPUI5 libraries in a summarized
form.
As SAPUI5 is based on CSS3, HTML5, and the new JavaScript API, only browsers with HTML5 capabilities are supported.
Depending on the platform your SAPUI5 applications run on, different browsers in different versions are supported. If you know which platform and which
browsers are used by your users, you can decide on which libraries to use for your application.
Caution
Microsoft Internet Explorer 11 (IE11) Enterprise Mode is not supported.
In this section:
sap.ui.core, sap.ui.layout, sap.ui.unified
Basic libraries, supporting all platforms or browsers that are supported by any of the other libraries
sap.m, sap.ui.table, sap.uxap, sap.tnt
Browser support for sap.m, sap.ui.table, sap.uxap, and sap.tnt libraries on iOS, Android, MacOS, and Windows platforms.
sap.ui.comp
Browser support for sap.ui.comp library on MacOS and Windows platforms
sap.viz
Browser support for the sap.viz library
sap.ui.vbm
Browser support for sap.ui.vbm library on iOS, Android, MacOS, and Windows platforms
sap.ui.vk
Browser support for sap.ui.vk library on iOS, Mac OS, and Windows platforms.
sap.suite.ui.commons
Overview of the browser support for sap.suite.ui.commons library on iOS, Android, Mac OS X, and Windows platforms.
sap.suite.ui.microchart
Overview of the browser support for sap.suite.ui.microchart library on iOS, Android, Mac OS X, and Windows platforms.
sap.ushell
Browser support for sap.ushell library on iOS, Android, BlackBerry, MacOS, and Windows platforms

sap.makit
Browser support for sap.makit library on iOS, Android, BlackBerry, MacOS, and Windows platforms
sap.ui.commons, sap.ui.ux3
Browser support for sap.ui.commons and sap.ui.ux3 libraries on Microsoft Windows and Mac OS platforms.
sap.gantt
Browser support for the sap.gantt library.
1.2.7.1 sap.ui.core, sap.ui.layout, sap.ui.unified

Basic libraries, supporting all platforms or browsers that are supported by any of the other libraries
sap.ui.core and sap.ui.layout are basic libraries used by every other library. They support a platform and a browser as soon as one of the other
libraries support it.
Also sap.ui.unified supports all platforms and browsers supported by at least one of the other libraries.
1.2.7.2 sap.m, sap.ui.table, sap.uxap, sap.tnt

Browser support for sap.m, sap.ui.table, sap.uxap, and sap.tnt libraries on iOS, Android, MacOS, and Windows platforms.
The following tables give an overview of the platforms supported by the sap.m, sap.ui.table, sap.uxap, and sap.tnt libraries using SAP Blue Crystal
theme.
Note
In general, only major versions that are also supported by the respective platform are supported.
For mobile operating systems, support is restricted to reference devices. For more information, see Device-Specific Policies.
iOS
iOS is supported as of platform version 8.
Browser Support
Safari Yes
Web View Yes
SAP Fiori Client Yes
Google Chrome Yes
Opera No
Android
Android is supported as of platform version 4.4.
Browser Support
Google Chrome Yes
Web View No
Opera No
Opera mini No
Firefox No
Mac OS
Mac OS X is supported as of version 10.10.
Browser Supported Version
Safari Version 8 or higher
Google Chrome Latest version
Windows
Touch is supported as of Windows 8.
Internet Explorer Version 11 or higher
Microsoft Edge Latest version
SAP Fiori Client Latest Version
Mozilla Firefox Latest version and Extended Support Release*

Safari None
Opera None
* In regards to handling touch events, there are some issues with Windows 8.
Windows 10 Mobile
SAP Fiori Client Latest version
Web View Latest version
Opera None
Exceptions
Caution
For the maxLines property of the sap.m.Text control, multiline ellipsis handling is not supported for all browsers and devices and is not
supported at all for right-to-left text direction. For more information, see Visual Degradations.
Certain new or more complex controls that do not yet offer mobile device support also do not support Windows Phone at this time, such as:
sap.m.FacetFilter and sap.m.MultiComboBox.
When using the redirect method of the sap.m.URLHelper control, note that some browsers fail to open a new window or tab. This is the case
for Windows Phone, for instance. As the redirect method is simply a wrapper of window.open native JavaScript, the problem is that Internet
Explorer 10 for Windows Phone is unable to return a valid window object for window.open . In addition, popup blockers can also prevent this
function from working properly.
In this section:
Device-Specific Policies
For mobile operating systems, support is restricted to reference devices.
Visual Degradations
Depending on the combination of device and browser, visual degradations may occur in the sap.m library.
Related Information
Windows 8 Support - Known Issues

This means support incidents should be provided on the listed reference devices and will be handled on these devices.
Apple
Apple always supports the 2 latest releases of the iOS operating system. SAPUI5 supports Apple mobile devices 3 years from the vendor device release date,
except defined otherwise. The following devices are supported:
Device End of Support Date
Apple iPhone 5c / 5s 22 October 2016
Apple iPhone 6 19 September 2017
Apple iPhone 6s 25 September 2018
Apple iPad Air 22 October 2016
Apple iPad Mini 2 22 October 2016
Apple iPad Air 2 22 October 2017
iPad Pro 9 September 2018
Android
Android OS based devices are very fragmented in matters of operating system variants and hardware diversity. SAPUI5 supports the following Android
reference devices until 3 years from vendor device release date:

Samsung S5 11 April 2017
Samsung S7 10 March 2019
Samsung Galaxy Tab Pro 10.1 27 February 2017
Windows Phone
SAPUI5 supports the following Windows Phone reference device until 3 years from vendor device release date:
Nokia Lumia 930 4 July 2017
Nokia Lumia 950 20 November 2018
1.2.7.2.2 Visual Degradations

Depending on the combination of device and browser, visual degradations may occur in the sap.m library.
The following sections give an overview of the known degradations.
sap.m.Text - maxLines (property), sap.m.Text - text (property), sap.m.ObjectListItem - title

(property), sap.m.ObjectHeader - title (property)
The visual aid for indicating multiline overflow is an ellipsis at the end of a line. This ellipsis is displayed if the text string exceeds the maximum number of
lines displayed on screen. Depending on the line-clamping support offered by your browser, this visual aid may not be displayed at all, meaning the text is
simply truncated without any visual indication that it is incomplete. The table below outlines which browsers fail to support the multiline ellipsis handling of the
maxLines property, and also shows examples of each visual degradation along with what the display should look like in each case:
Table 1: maxLines Visual Degradations
What it Should Look Like Visual Degradation
Google Chrome Mozilla Firefox Internet Explorer 10
placeholder Property in sap.m.Input and sap.m.TextArea

As there is no W3C specification for how to use the placeholder property, browser handling for this property varies greatly. Some browsers use a native
placeholder property, but for browsers that do not support this, SAP implements its own placeholder version.
The following overview outlines which browsers use which version, and which limitations or degradations apply in each case for the sap.m.Input control and
sap.m.TextArea control.
Table 2: placeholder Property in sap.m.Input

Browser Situation
Google Chrome Google Chrome supports the native placeholder property and displays the ellipsis
correctly, indicating that the placeholder text stretches beyond the field that is
currently visible

Internet Explorer Version 11 This version supports the native placeholder property but does not display the
ellipsis, instead it simply truncates the placeholder text string
Note
If you focus in the field, the placeholder disappears from view. If you leave the
focus without typing anything, the placeholder is then displayed again.
Mozilla Firefox Mozilla Firefox currently supports the native placeholder property and displays the
ellipsis correctly, indicating that the placeholder text stretches beyond the field that
is currently visible
Whereas sap.m.Input contains just a single line placeholder, sap.m.TextArea is a multiline control, meaning it brings with it different issues to the ones
listed above. These issues are different depending on the browser and are listed below.
Table 3: placeholder Property in sap.m.TextArea
Browser Situation
Google Chrome Google Chrome supports the native placeholder property and displays multiple
lines along with a scrollbar
Internet Explorer Version 11 This version does not use the native placeholder property, instead it uses the
placeholder version developed by SAP. This browser displays multiple lines along
with a scrollbar.
Note
Clicking the scrollbar sets focus from a technical perspective, meaning the
placeholder text disappears and makes scrolling impossible. Scrolling with the
mouse wheel does not set focus, and enables you to read the entire
placeholder text.
Mozilla Firefox Mozilla Firefox supports the native placeholder property but does not display a
scrollbar or an ellipsis, instead it simply truncates the placeholder text string
Issues Affecting sap.m.TextArea on iOS Devices
Note
There are several issues affecting iOS devices (as of version iOS 5), which are often mistakenly identified as errors relating to sap.m.TextArea
rendering. These are not visual degradations relating to sap.m. These rendering errors are inherent to the iOS operating system as of version 5, and also
occur even when SAPUI5 is not used at all, as shown in the examples below.
Problem Description
When the text entered inside a text box is long and does not fit into the fixed

When the text entered inside a text box is long and does not fit into the fixed
visible text area, the cursor then appears outside of the visible text box, as shown
in the graphic.
When choosing Select All to copy the contents of a text box on an iOS device,
the selection marked in blue continues outside the boundaries of the visible text
area, as shown in the graphic.
1.2.7.3 sap.ui.comp
Browser support for sap.ui.comp library on MacOS and Windows platforms
The following tables give an overview of the platforms supported by the sap.ui.comp library using SAP Blue Crystal theme.
Mac OS
On Mac OS X, Safari browser is supported in version 8 or higher.
Windows
Touch is supported as of Windows 8.
Internet Explorer 11 or higher
Mozilla Firefox Latest version and Extended Support Release
Safari None
Opera None
Caution
Windows Mobile is not supported.
1.2.7.4 sap.viz

Browser support for the sap.viz library
The sap.viz library relies on the open source component D3 which in turn relies on the availability of Scalable Vector Graphics (SVG).
Since the SVG file format is not fully supported by Mozilla Firefox ESR, the library is also not supported on this browser.
1.2.7.5 sap.ui.vbm
Browser support for sap.ui.vbm library on iOS, Android, MacOS, and Windows platforms
sap.ui.vbm is the Visual Business component in SAPUI5.
iOS
iOs is supported as of platform version 7.
Browser Supported
Safari Yes
Web View No
Google Chrome No
Opera No
Android
Android is supported as of platform version 4.0
Browser Supported
Android Browser Yes
Google Chrome Yes
Web View No
Opera No
Opera mini No
Firefox No
Mac OS
On Mac OS, Safari browser is supported in version 5.1 or higher.
Windows
Windows Desktop
Browser Supported
Mozilla Firefox No
Safari No
Opera No
Windows Tablet
For Windows Tablets only Internet Explorer is supported in the following versions:
Version Supported
10 Desktop Yes
11 Desktop Yes
10 Immersive Mode Yes
11 Immersive Mode Yes
Caution
Windows Mobile is not supported.
1.2.7.6 sap.ui.vk
Browser support for sap.ui.vk library on iOS, Mac OS, and Windows platforms.
sap.ui.vk is the Visual Interaction toolkit in SAPUI5. The following tables give an overview of the platforms and browsers supported by the sap.ui.vk library.

Note
The supported browsers listed are all WebGL-compatible.
iOS
iOS is supported as of platform version 8.
On iOS, Safari browser is supported in versions 8 or higher.
Mac OS
Mac OS is supported as of platform version 10.10.
On Mac OS, Safari browser is supported in versions 8 or higher.
Windows
Windows Desktop
Windows is supported as of platform version 7.
Browser Supported
Mozilla Firefox (version 39 or higher) Yes
Google Chrome (version 43 or higher) Yes
Internet Explorer 11 Yes
Microsoft Edge Yes
Note
The sap.ui.vk library is not supported for Internet Explorer 11 on Windows 8.0.
Windows Tablet
Windows is supported in platform version 8.1 only.
On Windows tablets, Internet Explorer is supported in version 11 only.
1.2.7.7 sap.suite.ui.commons
Overview of the browser support for sap.suite.ui.commons library on iOS, Android, Mac OS X, and Windows platforms.
The following tables give an overview of the platforms supported by the sap.suite.ui.commons library using SAP Blue Crystal theme.
iOS
iOs is supported as of platform version 8.4.1.
Browser Supported
Safari Yes
Web View No
Google Chrome No
Opera No
Android
Android is supported as of platform version 4.4.2.
Browser Supported
Android Browser Yes
Google Chrome Yes
Web View Yes
Opera No
Opera mini No
Firefox Yes
Mac OS

Browser Supported
Safari Yes
Mozilla Firefox No
Opera No
Windows
Note
Windows Touch is supported as of Windows 8 and Internet Explorer 11.
Windows 7
Browser Supported
Internet Explorer 11
Edge No
Mozilla Firefox Latest version
Safari No
Opera No
Windows 8
Browser Supported
Safari No
Opera No
Windows 10
Browser Supported
Internet Explorer 11 and Edge
Safari No
Opera No

Apple
Android

Windows Phone
Nokia Lumia 1520 22 October 2016
Nokia 950 28 November 2018
1.2.7.8 sap.suite.ui.microchart
Overview of the browser support for sap.suite.ui.microchart library on iOS, Android, Mac OS X, and Windows platforms.
The following tables give an overview of the platforms supported by the sap.suite.ui.microchart library using SAP Blue Crystal theme.
iOS
iOs is supported as of platform version 8.4.1.
Browser Supported
Safari Yes
Web View No
Google Chrome No
Opera No
Android
Android is supported as of platform version 4.4.2.
Browser Supported
Android Browser Yes
Google Chrome Yes
Web View Yes
Opera No
Opera mini No
Firefox Yes
Mac OS
Browser Supported
Safari Yes
Mozilla Firefox No
Opera No
Windows
Note
Windows Touch is supported as of Windows 8 and Internet Explorer 11.
Windows 7
Browser Supported

Edge No
Safari No
Opera No
Windows 8
Browser Supported
Safari No
Opera No
Windows 10
Browser Supported
Internet Explorer 11 and Edge
Safari No
Opera No

Apple
Android
Windows Phone
Nokia Lumia 1520 22 October 2016
Nokia 950 18 November 2018
1.2.7.9 sap.ushell
1.2.7.9 sap.ushell
Browser support for sap.ushell library on iOS, Android, BlackBerry, MacOS, and Windows platforms
The sap.ushell library supports the same browsers and platforms as sap.m, sap.ui.table, sap.uxap, sap.tnt.
1.2.7.10 sap.makit
Browser support for sap.makit library on iOS, Android, BlackBerry, MacOS, and Windows platforms
iOS
iOs is supported in platform version 5 and 6.
Browser Supported
Safari Yes
Web View Yes
Google Chrome No
Opera Mini No
Android
Android is supported as of platform version 2.3 until version 4.2
Browser Supported
Android Browser Yes
Google Chrome Yes
Web View Yes
Opera No
Opera mini No
Firefox No
BlackBerry
Blackberry is supported as of platform version 10.
Browser Supported
Blackberry Browser Yes
Web View Yes
Opera mini No
Mac OS
Safari in version 5.1 or higher is enabled for development scenario, but not productively supported on Mac OS.
Windows
Safari and Chrome are enabled for development scenario, but not productively supported on Windows.
1.2.7.11 sap.ui.commons, sap.ui.ux3

Browser support for sap.ui.commons and sap.ui.ux3 libraries on Microsoft Windows and Mac OS platforms.
Microsoft Windows
Microsoft Internet Explorer 11 or higher
Mozilla Firefox Latest version and Extended Support Release (ESR)
Caution
Touch is not supported for Microsoft Windows.

Windows Phone / Windows Mobile is not supported.
Mac OS
On Mac OS X platform, Safari browser with version 8 and higher is supported.
Caution
Touch is not supported for Mac OS platforms.
1.2.7.12 sap.gantt
Browser support for the sap.gantt library.
The following sections provide an overview of the platforms supported by the sap.gantt library using the SAP Blue Crystal theme.
Mac OS
On the Mac OS platform, the latest version of Google Chrome is supported.
Caution
Microsoft Windows Platforms

Browser Supported
Microsoft Internet Explorer 11 or later
Caution
Demo Kit and Platform-Specific Documentation

The SAPUI5 documentation is included in the Demo Kit. The Demo Kit also provides you with technical documentation and samples. There are also platform-
specific variants of the documentation available at other locations.
Demo Kit
The Demo Kit contains the following:
Developer Guide with the SAPUI5 documentation.
Explored app, which gives a detailed view of almost every control, including detailed information about the corresponding properties, aggregations,
events and methods. In addition, it also provides samples including a code view that allows you to easily copy any code snippets you may need.
Note
You can also view and download the code for our tutorials here. Just search for Tutorial in the Explored app. For more information, see Tutorials.
API Reference , which includes JavaScript documentation for the framework and control API.
Demo Apps , which also showcase actual samples.
Icons with an overview of all icons that are available with SAPUI5.
You can find the Demo Kit at the following locations:
For SAP NetWeaver Application Server for ABAP, use the following URL, replacing <host> with the host name and <port> with the port number of your
system: http://<host>:<port>/sap/bc/ui5_demokit/
For SAP NetWeaver Application Server for Java, use the following URL, replacing <host> with the host name and <port> with the port number of your
system: http://<host>:<port>/sapui5-sdk
For the SAP HANA Cloud Platform version, go to https://sapui5.hana.ondemand.com/
For the OpenUI5 version, go to https://openui5.hana.ondemand.com/.
Note
You can find the latest released version of the Demo Kit at https://sapui5.hana.ondemand.com/sdk/. If you want to see the Demo Kit for a specific
SAPUI5 version, simple add the version number to the URL, for example https://sapui5.hana.ondemand.com/1.32.7/
Check the available versions with respective maintenance status at https://sapui5.hana.ondemand.com/versionoverview.html.
Platform-Specific Documentation

Platform-Specific Documentation
SAPUI5 can be used on the following platforms:
SAP HANA
SAP HANA Cloud Platform
UI technologies in SAP NetWeaver for SAP NetWeaver 7.4 or higher
User interface add-on for SAP NetWeaver for SAP NetWeaver Application Server 7.3x
You can find platform-specific documentation at the following places:
For SAP HANA open the SAP Help Portal at http://help.sap.com/hana_platform/ and choose Development and Modeling SAP HANA Developer
Guide . In this guide, you can find SAPUI5-specific information under Building UIs Building User Interfaces with SAPUI5 for SAP HANA .
For SAP HANA Cloud Platform, use the external Demo Kit that is available online at https://sapui5.hana.ondemand.com.
For the UI technologies in SAP NetWeaver, open the SAP Help Portal at SAP NetWeaver, select your version, and choose Application Help UI
Technologies in SAP NetWeaver SAPUI5: UI Development Toolkit for HTML5 .
For the user interface add-on for SAP NetWeaver, open the SAP Help Portal at http://help.sap.com/nw-uiaddon/ and choose Application Help
SAPUI5: UI Development Toolkit for HTML5 .
Note
This is the documentation version for SAP NetWeaver Application Server for ABAP and the User Interface Add-On for SAP NetWeaver.
1.2.9 Development Environment

This part of the documentation gives you guidance on the most common and recommended use cases of the installation, configuration and setup of the UI
development toolkit for HTML5 (SAPUI5) development environment.
Note
You can install SAPUI5 on different platforms. The license and maintenance conditions of the respective platforms also apply for SAPUI5. If you use
SAPUI5 tools on SAP HANA Cloud Platform, for example, the license and maintenance conditions of the SAP HANA Cloud Platform apply.
Important SAP Notes for the Installation

Before you start the installation process, read the following SAP Notes. Make sure that you have the up-to-date version of each SAP Note. You can find them
on SAP Service Marketplace at http://support.sap.com/notes .
Note Number Title Description
1666368 Installing UI add-ons for SAP NetWeaver Describes the installation of the ABAP components of
UI add-on for SAP NetWeaver
1666369 SPs for UI add-ons for SAP NetWeaver Contains information about add-on support packages
for UI add-on for SAP NetWeaver
1686090 Translation Object for SAPUI5 (ABAP) To use the translation feature with the SAPUI5 ABAP
team provider in the UI add-on in an SAP NetWeaver
7.0 EHP3/7.31 system, implement this SAP Note in the
translation system to enable the translation of text
elements.
1582870 ABAP XSS Escaping Support We highly recommend that you implement this SAP
Note to support ABAP XSS escaping.
Depending on your use case, you can choose one of the following development environments.
Note
You can also build native SAP HANA applications using SAPUI5. For more information, see the SAPUI5 for SAP HANA Development Tutorials in the
SAP HANA Developer Guide on SAP Help Portal at http://help.sap.com/hana_platform/ under Development and Modeling SAP HANA Developer

Guide Building UIs .
In this section:
App Development Using OpenUI5
Develop apps using OpenUI5 and the development environment (editor and Web server) of your choice. You can either download all of the sources or refer
to the online version of OpenUI5.
App Development Using SAP Web IDE
SAP Web IDE is a web-based development environment that is optimized for developing SAPUI5 complex apps using the latest innovations, developing
and extending SAP Fiori apps, developing mobile hybrid apps, and extending SAP Web IDE with plugins and templates.
App Development Using SAPUI5 Tools for Eclipse
Used for developing apps for simple use cases. The SAPUI5 application development tools for Eclipse provide wizards to support you in creating apps in an
easy way. With the application project wizard, the necessary application skeleton containing views and controllers will automatically be created.
Node.js-Based Development Environment
Used for modifying OpenUI5. The environment is based on Node.js, used as a server, with a build process that is based on Grunt. This section provides
information for the initial setup, development roundtrip, and tests execution.
Development for Hybrid Web Containers
You can develop mobile apps as hybrid app consisting of a native app wrapper, for example PhoneGap, and an HTML viewer to display the content on the
user interface.
SAPUI5 Runtime Installation (SAP NetWeaver 7.3 EHP1 or Lower)
Installation prerequisites and installation process for SAPUI5 Runtime
App Development Using OpenUI5

Develop apps using OpenUI5 and the development environment (editor and Web server) of your choice. You can either download all of the sources or refer to
the online version of OpenUI5.
Download OpenUI5
The default way of downloading and installing OpenUI5 is to get the runtime from the OpenUI5 home page at http://openui5.org and deploy it on a Web
server.
1. Go to http://openui5.org/download.html#stableRelease and choose Download OpenUI5 Runtime to download a ZIP file containing the OpenUI5 sources.
2. Unzip this file and put the entire content on the Web server where your application is running (or you can even package it within your application to
deploy it along with the app).
3. In your applications main HTML file, load OpenUI5 by referring to the resources/sap-ui-core.js file that was contained in the ZIP file. (See
Standard Variant for Bootstrapping.)
Using OpenUI5 Sources from a Content Delivery Network

If you don't want to download the files and don't want to include them in your deployment, you can use the online version of OpenUI5. For more information,
see Variant for Bootstrapping from Content Delivery Network.
Note
You can find a list of all available OpenUI5 versions here: https://openui5.hana.ondemand.com/versionoverview.html.
Only use the Stable version for productive apps. Nevertheless, if you also want to test the Preview version, you are very welcome to send us your
feedback!
Consume OpenUI5 Using Bower

You can also use the package management system Bower to develop your application. In this case, you simply add OpenUI5 to the bower.json file as a
dependency, and it will be included automatically:
{
"name": "some-openui5-app",
"description": "Sample of an OpenUI5 app",
"private": true,
"dependencies": {
"openui5-sap.ui.core": "openui5/packaged-sap.ui.core#~1.28.10",
"openui5-sap.m": "openui5/packaged-sap.m#~1.28.10",
"openui5-themelib_sap_bluecrystal": "openui5/packaged-themelib_sap_bluecrystal#~1.28.10"
}
}
You can find a sample application using this mechanism and describing its usage on GitHub at https://github.com/SAP/openui5-sample-app.
For more information on how to install and use Bower, see the Bower home page at http://bower.io .
App Development Using SAP Web IDE

SAP Web IDE is a web-based development environment that is optimized for developing SAPUI5 complex apps using the latest innovations, developing and
extending SAP Fiori apps, developing mobile hybrid apps, and extending SAP Web IDE with plugins and templates.
Key use cases:
Develop new SAP Fiori and SAPUI5 apps
Extend SAP Fiori apps
Develop SAPUI5 mobile hybrid apps (HAT plug-in)

Extend SAP Web IDE with new plug-ins and templates
A trial version of SAP Web IDE can be accessed through the SAP HANA Cloud Platform. For more information on how to get an account and start using SAP
Web IDE, see the documentation of SAP Web IDE at https://help.hana.ondemand.com/webide/frameset.htm?6284a94889db4f3cad001ba674282f20.html.
In this section:
Get a Trial Account and Access SAP Web IDE
Steps for creating an SAP HANA trial account
Start SAP Web IDE
Initial Steps in SAP Web IDE
Create a neo-app.json Project Configuration File
The neo-app.json file contains all project settings for SAP Web IDE and is created in the root folder of your project. It is a JSON format file consisting of
multiple configuration keys. The most important setting for you to configure is the path where the SAPUI5 runtime is located when starting the app.
Create an index.html File
A minimalistic index.html file is needed to test the project configuration. This file contains the SAPUI5 bootstrap and a sap.m.Text control that
displays the text "SAPUI5 is loaded successfully!".
Run the App
SAP Web IDE comes with integrated testing features that let you run the app on a central server without having to set up any additional infrastructure. You
can run the app by selecting the src/index.html file and clicking the run button in the header toolbar.
Create a Northwind Destination
Configure a destination in the SAP HANA Cloud Platform Cockpit in order to bypass the same-origin policy of the browser.
Get a Trial Account and Access SAP Web IDE

Steps for creating an SAP HANA trial account
If you do not have access to SAP Web IDE, you can create a free account. To create an account, simply register an SAP HANA trial account at
https://account.hanatrial.ondemand.com/ and log on afterwards.
After logging on, choose Services in the navigation bar of the SAP HANA Cloud Platform cockpit and open the detailed information on your SAP Web IDE by
choosing the SAP Web IDE tile.
Selecting Open SAP Web IDE leads you to your personal SAP Web IDE.

Note
You can bookmark this link to access SAP Web IDE later.
Start SAP Web IDE

Initial Steps in SAP Web IDE
1. Open SAP Web IDE and wait until the initialization has finished.
When you start it for the first time, you will see a home screen containing more information about SAP Web IDE.
2. Change to the Development perspective by clicking the icon with the code symbol on the left sidebar.
You now see a folder list with an entry Workspace on the left side and an empty code editor on the right side.
3. Create your project within the Workspace folder by choosing File New Folder from the menu or Ctrl + Alt + Shift + N . Enter, for example,
myProject as the folder name.
1.2.9.2.3 Create a neo-app.json Project Configuration File

The neo-app.json file contains all project settings for SAP Web IDE and is created in the root folder of your project. It is a JSON format file consisting of
multiple configuration keys. The most important setting for you to configure is the path where the SAPUI5 runtime is located when starting the app.
You do this using the routes key and defining an array of resource objects. For running an SAPUI5 tutorial, you only need two entries - one that configures
SAPUI5 to be available with the path /resources, and another one that configures the test resources needed for the SAP Fiori launchpad integration with the
path /test-resources.
Create two configuration objects that contain a path, a target, and a description attribute with more configuration settings. The path and the
entryPath values will point to the location on the server where the SAPUI5 resources will be stored.
SAP Web IDE reads these settings automatically when running the app. You can see the whole configuration file in the code block below. Optionally, you can
add the key welcomeFile to configure the entry point to your app. In web applications, this is typically the index.html file.
Note
Depending on which SAP Web IDE version you are using, you might have to configure the project to run against the "snapshot" version of SAPUI5,
otherwise the application will be launched with the SAPUI5 release that is delivered with SAP Web IDE. This is usually the latest version that is released
publicly to customers.
You can check which version of SAPUI5 is loaded by opening the SAPUI5 debugging tools with CTRL + SHIFT + ALT + P . If the version is too old for
certain features of the tutorial, you have to add the version attribute to the target configuration entry and set the value to snapshot. In SAP-internal
versions of SAP Web IDE, this will load the nightly build of SAPUI5.
Procedure
1. Select the New File icon and enter neo-app.json as the file name.

2. Open the newly created file from the tree structure on the left side of the screen.
3. Paste the following code in the neo-app.json and select Save :
{
"welcomeFile": "index.html",
"routes": [
{
"path": "/resources",
"target": {
"type": "service",
"name": "sapui5",
"version": "snapshot",
"entryPath": "/resources"
},
"description": "SAPUI5 Resources"
},
{
"path": "/test-resources",
"target": {
"type": "service",
"name": "sapui5",
"entryPath": "/test-resources"
},
"description": "SAPUI5 Test Resources"
}
]
}
1.2.9.2.4 Create an index.html File

A minimalistic index.html file is needed to test the project configuration. This file contains the SAPUI5 bootstrap and a sap.m.Text control that displays
the text "SAPUI5 is loaded successfully!".
1. Choose the New Folder icon in the header toolbar and enter src as the folder name.
2. Select the newly created folder and create a new index.html file inside it by choosing the New File icon.
3. Paste the following code in the newly created index.html file and select Save :
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta charset="utf-8">
<title>SAPUI5 Walkthrough</title>
<script
id="sap-ui-bootstrap"
src="/resources/sap-ui-core.js"
data-sap-ui-theme="sap_bluecrystal"
data-sap-ui-modules="sap.m.library"
data-sap-ui-compatVersion="edge"
data-sap-ui-preload="async" >
</script>
<script>
sap.ui.getCore().attachInit(function () {
new sap.m.Text({
text : "SAPUI5 is loaded successfully!"
}).placeAt("content");
});
</script>
</head>
<body class="sapUiBody" id="content">
</body>
</html>
1.2.9.2.5 Run the App

SAP Web IDE comes with integrated testing features that let you run the app on a central server without having to set up any additional infrastructure. You can
run the app by selecting the src/index.html file and clicking the run button in the header toolbar.
This launches the app on a central server and a testing tool that allows you to configure the screen size and orientation of the device. This feature can be used
to test apps that are specifically targeted for mobile, tablet, and desktop devices. You can change the resolution and the orientation in the header bar very
easily.
If you don't want to run the app in the testing tool, you can adjust the Run Configurations for the project:
1. Right-click any file in the project and select Run Run Configurations .
2. Choose + and select Web Application to add a new run configuration.
3. To save the configuration and run your project, choose Save and Run .
Note
For more information on how to run projects, see the documentation of SAP Web IDE at https://help.hana.ondemand.com/webide/frameset.htm?
ec68f058007241be87f5ad4364e6e87b.html.

1.2.9.2.6 Create a Northwind Destination
Configure a destination in the SAP HANA Cloud Platform Cockpit in order to bypass the same-origin policy of the browser.
To be able to test your app, you can use a remote OData service that provides product data from the Northwind demo service of the OData group.
In the navigation bar of the SAP HANA Cloud Platform Cockpit, choose Destinations and then choose New Destination in the toolbar.
Enter the following values into the corresponding fields:
Field Value
Name northwind
Type HTTP
Description Northwind OData Service
URL http://services.odata.org
Proxy Type Internet
Authentication NoAuthentication
Also, enter the following properties in the section Additional Properties :
Property Value
WebIDEEnabled true
WebIDESystem Northwind
WebIDEUsage odata_gen
With this configuration you can use the destination for any app inside SAP Web IDE. Whenever an app calls a (local) service beginning with
/destinations/northwind/*, the created destination becomes active as a simple proxy. This helps to prevent any possible issues related to the same-
origin policy of browsers.
App Development Using SAPUI5 Tools for Eclipse

Used for developing apps for simple use cases. The SAPUI5 application development tools for Eclipse provide wizards to support you in creating apps in an
easy way. With the application project wizard, the necessary application skeleton containing views and controllers will automatically be created.
Note
We recommend this development environment only for experienced developers, and only for simple use cases. For all other purposes we recommend
using the SAP Web IDE. For more information, see App Development Using SAP Web IDE.
In this section:
Installing SAPUI5 Tools for Eclipse
Required information for the installation, upgrade, and uninstallation of SAPUI5 tools.
Using SAPUI5 Tools for Eclipse
The SAPUI5 application development tools for Eclipse provide wizards to support you in creating SAPUI5 apps in an easy way. With the SAPUI5
application project wizard, the necessary application skeleton containing view(s) and controller will automatically be created.
Installing SAPUI5 Tools for Eclipse

Required information for the installation, upgrade, and uninstallation of SAPUI5 tools.
Before you start the installation, make sure that you have the required software versions installed and that you have downloaded the respective Software
components.
Note
There are differences and specifics for the required software, software components, and installation steps based on the product you are using.

Required Software for Installing and Running SAPUI5 Tools
To install and run SAPUI5 tools, the following software has to be installed:
Java Runtime Environment (JRE): JRE version, as supported by the used Eclipse release (32 bit or 64 bit). For example, for Eclipse Mars, JRE 1.7 is
recommended but JRE 1.8 is supported as well. As Eclipse Neon only supports JRE 1.8, an upgrade of the JRE is mandatory.
Operating system: Windows XP, Vista, 7 (32- or 64-Bit), 8/8.1
Browser: Not relevant, except for Internet Explorer 9.0 or higher for embedded application preview
To install the SAPUI5 tools for SAP HANA, you need to install the SAP HANA Studio according to the installation information provided on the SAP Help Portal
under help.sap.com/hana_platform Installation and Upgrade Information . Make sure that the features listed in the following table are installed:
Name Technical ID
Eclipse Faceted Project Framework (Version 3.6.1) org.eclipse.wst.common.fproj
Eclipse Faceted Project Framework JDT Enablement (Version 3.6.1) org.eclipse.wst.common.fproj.enablement.jdt
Eclipse Java EE Developer Tools (Version 3.6.1) org.eclipse.jst.enterprise_ui.feature
Eclipse JavaWebEE Developer Tools (Version 3.6.1) org.eclipse.jst.web_ui.feature
WST Common Core (Version 3.6.1) org.eclipse.wst.common_core.feature
WST Server Adapters org.eclipse.wst.server_adapters
Note
Make sure that you have write permission for the directory you use for the Eclipse installation, or start Eclipse as Administrator.
If one of the features is already available and cannot be overwritten by a newer version, only add the features that are not yet available and leave the other
features unchanged.
If you install the features from the Eclipse Release Train Update, it may be necessary to deselect the Group Items by Category and Show only latest
versions of available software checkboxes.
To install the SAPUI5 tools for SAP NetWeaver, the following software has to be installed:
SAPUI5 ABAP Team Provider to connect to an ABAP backend system on SAP NetWeaver 7.3 EHP1, or 7.40 or higher
If you want to use the SAPUI5 ABAP Team Provider to connect to an ABAP backend system, the following additional prerequisites are required:
User interface add-on for SAP NetWeaver 2.0
AiE Communication Framework
The AIE Communication Framework is part of the ABAP development tools for SAP NetWeaver. Install the complete ABAP development tools
according to the installation procedure in the Installing ABAP Development Tools for SAP NetWeaver guide and the Configuring the ABAP Back-
end for ABAP Development Tools guide.
Eclipse Platform
The SAPUI5 tools run on the following Eclipse versions: Mars 4.5.0 and Neon 4.6.0. There are two options for the Eclipse platform: Either an 'Eclipse
IDE for Java EE Developers' bundle or an 'Eclipse Classic 4.2' bundle. Depending on the bundle you choose, you may be required to install additional
features according to this list:
Name Technical IDE Min. version Contained in Eclipse JEE Contained in Eclipse Classic
Bundle Bundle
Eclipse Platform org.eclipse.platform 4.5.0 (Mars) Yes Yes
Eclipse Faceted Project org.eclipse.wst.common.fproj 3.1.0 Yes No

Framework
Eclipse Faceted Project org.eclipse.jst.common.fproj.en 3.1.0 Yes No

Framework JDT Enablement ablement.jdt
Eclipse Java Development org.eclipse.jdt 3.5.0 Yes Yes

Tools
Eclipse Java EE Developer org.eclipse.jst.enterprise_ui.fea 3.1.0 Yes No

Tools ture
Eclipse Java Web Developer org.eclipse.jst.web_ui.feature 3.1.0 Yes No

Tools / JST Web UI
EMF - Eclipse Modeling org.eclipse.emf 2.0.0 Yes No

Framework Runtime and Tools
Graphical Editing Framework org.eclipse.gef 3.5.0 Yes No

GEF
JavaScript Development Tools org.eclipse.wst.jsdt.feature 1.1.0 Yes No
WST Common Core org.eclipse.wst.common_core.f 3.1.0 Yes No

eature
WST Server Adapters org.eclipse.wst.server_adapter 3.2.300 Yes No

s
Note
Make sure that you have write permission for the directory you use for the Eclipse installation, or start Eclipse as Administrator.
Required Software Components for SAPUI5 Tools

Required Software Components for SAPUI5 Tools
Depending on the product you are using, the following software components have to be downloaded and installed:
Product Required Software Copmponents
SAP NetWeaver Download the following components from the SAP Software Download Center on
SAP Service Marketplace at http://service.sap.com/swdc:
SAPUI5 TOOLS IDE PLUGIN 2.00
SAPUI5 TEAM PROV IDE 2.00
To find the respective download packages, search for the above mentioned
component names. The search option as well as other options for finding the
installation packages for your component are described on the Find your Software
tab on the start page of the SAP Software Download Center.
SAP HANA For the installation of SAPUI5 tools on SAP HANA XS, download the SAPUI5
TOOLS IDE PLUGIN 1.00 component from the SAP Software Download Center on
SAP Service Marketplace at http://service.sap.com/swdc.
SAP HANA Cloud Platform For the installation of SAPUI5 on SAP HANA Cloud Platform, the SAPUI5 tools are
contained in the SAP HANA Cloud Tools and you can install them as described in
https://tools.hana.ondemand.com/#sapui5.
Installation Process for SAPUI5 Tools

To install SAPUI5 tools, proceed as follows:
1. Launch your Eclipse workbench.
2. Open the installation wizard by choosing Help Install New Software .
3. In the Work with field of the installation wizard, specify the target directory of the package.
To add the new installation directory, choose Add and then choose Archive to specify the location. Enter a name for your local software site.
4. Select all features for the UI development toolkit for HTML5 and choose Next .
5. Review the feature groups to be installed and choose Next .
6. Accept the terms of the license agreement and choose Finish to initiate the installation of selected feature groups.
7. In the Certificates dialog confirm the certificates from Eclipse.org and SAP with OK .
8. To apply the changes of the installation procedure, restart the Eclipse workbench.
9. To check, whether the installation has been successful, proceed as follows:
For application development open Eclipse and choose File New Other ... SAPUI5 Application Development Application Project . If the
installation has been successful, the New Application Project wizard opens.
To check the team provider for the SAPUI5 ABAP repository, open Eclipse and choose File New Other ... SAPUI5 Application
Development Application Project . Select the new project and choose Context Menu Team Share Project... . If the installation has been
successful, SAPUI5 ABAP Repository appears in the list.
Using SAPUI5 Tools for Eclipse

The SAPUI5 application development tools for Eclipse provide wizards to support you in creating SAPUI5 apps in an easy way. With the SAPUI5 application
project wizard, the necessary application skeleton containing view(s) and controller will automatically be created.
Creating SAPUI5 Apps

The SAPUI5tools support you in creating applications according to MVC. In this section we guide you through a simple example. You will create a SAPUI5
application project, which includes a control, a method in the controller and an additional view.
Utilities
With Eclipse you can make use of utilities for JavaScript development. Additionally SAPUI5 provides templates and snippets.
JavaScript Code Completion
The Eclipse JavaScript Development Tools (JSDT) provide an editor which parses scripts and offers code completion functionality. The core libraries for
the code completion are made available automatically.
In this section:
Create an SAPUI5 Application Project
To create an SAPUI5 Application Project, you must have installed the SAPUI5 Application Development feature in your Eclipse installation.
Add a Control to Your View
In your SAPUI5 application project, the first step to build your application is to add a control to your view and implement a method to react on user
interaction. In this case you create a button and implement a function to react when the user presses it.
Implement a Method in the Controller
All functions that are not directly related to the user interface should be handled in the controller to ensure clear separation between UI and data. In this
case you add a method to handle the event, which is attached to a button.
Create an Additional View
A SAPUI5 application view can only be created for a SAPUI5 application project that has been created with the SAPUI5 Application Wizard and not for
other kinds of projects.
Integrate a New View
To integrate a new view, you can either add it to index.html or nest it into another view.
When using the SAPUI5 tools, code completion is enabled automatically, without the tools, you need to enable it.
Linking your Eclipse Editor to the Demo Kit
You can use Quick Fixes to display the API documentation of a SAPUI5 control in the Demo Kit.

Use JavaScript and XML Templates
You can add SAPUI5 control-specific templates for JavaScript code. Such templates are available, for example, in JavaScript views of SAPUI5 application
tools development.
SAPUI5 Snippets
SAPUI5 snippets are templates and examples on how to use the SAPUI5 runtime and controls.
Running an App in the Application Preview
You access the application preview using the Web App Preview, provided with the embedded Jetty server. You can quickly check on your application and
open it in the default browser.
Create an SAPUI5 Application Project

To create an SAPUI5 Application Project, you must have installed the SAPUI5 Application Development feature in your Eclipse installation.
Procedure
1. Start the New SAPUI5 Application Project wizard in the Eclipse by choosing New Other ... SAPUI5 Application Development Application
Project .
2. Enter the following project-related data:

Project name
Location (optional, prefilled from the current workspace)
Library 'sap.m' (default) or 'sap.ui.commons'
Select Create an Initial View
Views can also be added later using the SAPUI5 Application View wizard
3. Enter the following view-related data:

Choose the folder in which the view shall be created
Enter a unique name for your view
Choose the Development Paradigm .

Results
After finishing the wizard, the system performs the following steps:
A new dynamic Web project is created. All relevant files are created in the WebContent folder.
A prefilled index.html is created which contains sap.ui.commons lib and sap_bluecrystal theme in the bootstrap in case of a desktop target
device and the sap.m lib and sap_mvi theme in case of mobile target device.
In WEB-INF folder a web.xml file is created which contains settings for resource handling and the use of SimpleProxyServlet.
The installed SAPUI5 UI lib plugins are automatically added to the Java build path and added to the deployment assembly.
TheSAPUI5 class path container (if available) is automatically added to the JavaScript include path.
The index.html page is opened in the standard editor.
Inside the JavaScript block of index.html, code completion is available, see JavaScript Code Completion.
An automatic switch to the J2EE perspective is performed.
If you have selected the Create an Initial View option on the first page of the SAPUI5 Application Project wizard, a view and a view controller are
created and the coding to call the view is added to the index.html file.
Next Steps
Add a Control to Your View
Create an Additional View
Integrate a New View
Related Information
Use JavaScript and XML Templates
SAPUI5 Snippets
Linking your Eclipse Editor to the Demo Kit
1.2.9.3.2.2 Add a Control to Your View

In your SAPUI5 application project, the first step to build your application is to add a control to your view and implement a method to react on user interaction.
In this case you create a button and implement a function to react when the user presses it.
Procedure
To add a control to your view, add the following coding depending on the type of your view:
In a JS view add the following to the createContent function
var aControls = [];
var oButton = new sap.ui.commons.Button({
id : this.createId("MyButton"),
text : "Hello JS View"
});
aControls.push(oButton.attachPress(oController.doIt));

return aControls;
In an HTML view add the following to the template tag:
<div data-sap-ui-type="sap.ui.commons.Button" id="MyButton"
data-text="Hello HTML View" data-press="doIt">
</div>
In an XML view add the following coding to the core tag

<Button id="MyButton" text="Hello XML View" press="doIt"/>
In a JSON view add the following to the content function
"Type":"sap.ui.commons.Button",
"id":"MyButton",
"text":"Hello JSON View",
"press":"doIt"
A button is added to your view with an event that is triggered when the user presses it.
Next Steps
The doIt method, which is called in each of these view types, is implemented in the controller:
1.2.9.3.2.3 Implement a Method in the Controller

All functions that are not directly related to the user interface should be handled in the controller to ensure clear separation between UI and data. In this case
you add a method to handle the event, which is attached to a button.
Prerequisites
You've created a button as described in: Add a Control to Your View
Procedure
To handle this event, add the following function to the controller:
doIt : function(oEvent) { alert(oEvent.getSource().getId() + " does it!"); }
1.2.9.3.2.4 Create an Additional View

A SAPUI5 application view can only be created for a SAPUI5 application project that has been created with the SAPUI5 Application Wizard and not for other
kinds of projects.
Context
A SAPUI5 application view name needs to be unique inside the project folder.
The specified folder for a SAPUI5 application view needs to be WebContent/<application name> or a sub folder.
Procedure
1. Choose New Other... SAPUI5 Application Development View to open the New SAPUI5 Application View wizard.
2. Fill in the required data:

Select the SAPUI5 application project, in which you want to create the view.
Select a folder, in which you want to store the view (default is WebContent/<application name>).
Enter a name for the view.
Select the development paradigm with which you want to develop your view.

Results
When you finish the wizard, the system creates the view in the specified folder. The file name suffix indicates the development paradigm:
<viewname>.view.js for JavaScript views
<viewname>.view.xml for XML views
<viewname>.view.json for JSON views
<viewname>.view.html for HTML views
If the corresponding index.html file contains sap.m lib in the bootstrap, that is, if the SAPUI5 application project has been created for a mobile target device,
the view contains coding for instantiating a mobile page control sap.m.Page.
The system also creates a controller file <viewname>.controller.js with draft coding.
For JavaScript views, code completion is available, see JavaScript Code Completion.
Note
If you rename the view or controller file, or move them to a different folder, the coding in the view and controller and in the places where the view is used
needs to be adapted manually.
Related Information
Views
1.2.9.3.2.5 Integrate a New View

To integrate a new view, you can either add it to index.html or nest it into another view.
Prerequisites
If you create a new view for an existing SAPUI5 application project, the view needs to be manually called.
Procedure
To call a view, choose from the following options:
Directly embed the new view in the index.html page
All Views can be nested independent of the view type. Each view type behaves like any SAPUI5 control. The viewName property defines, which views
are embedded. To nest a view, proceed according to the given examples:
For XML view type:
<core:View controllerName="sap.hcm.Address" xmlns="sap.ui.commons" xmlns:core="sap.ui.core"
xmlns:html="http://www.w3.org/1999/xhtml">
<Panel>
<core:JSView id="myJSView" viewName="sap.hcm.Bankaccount" />
</Panel>
<core:View>
For HTML views, the nested view looks as follows:

<template data-controller-name= "example.mvc.test" >
<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>
</template>
1.2.9.3.2.6 JavaScript Code Completion

When using the SAPUI5 tools, code completion is enabled automatically, without the tools, you need to enable it.
Automatic Code Completion for SAPUI5 Application Projects

The Eclipse JavaScript Development Tools (JSDT) provide an editor which parses scripts and offers a code completion functionality.
Code Completion for SAPUI5 Views

For JavaScript views, code completion is available.
Enabling Code Completion for Other Projects

If you are not working with a SAPUI5 application project, you can perform the following preparing steps to add the required SAPUI5 core libraries to the
JavaScript include path.
Ensure that the JavaScript Facet is set and proceed as follows:
1. Open Project Properties .
2. Select Project Facets .
3. If you do not see the list of all possible facets, click the link: Convert to facet form and wait a second to see all available facets.
4. Mark JavaScript Facet on the same view.

5. Leave the project properties.
Your project now has the JavaScript facet. Now you can add the SAPUI5 core libraries. Proceed as follows:
Open Project Properties .
Choose JavaScript Include Path .
Select Add JavaScript Library .
Select SAPUI5 .
You should now be able to see the following JavaScript resources in your project:
1.2.9.3.2.7 Linking your Eclipse Editor to the Demo Kit

You can use Quick Fixes to display the API documentation of a SAPUI5 control in the Demo Kit.
Procedure
1. Place the cursor on the actual SAPUI5 control name in your JavaScript code or in your XMLView. The name of the control in JavaScript code usually
starts with sap.
2. To see all available Quick Fixes, press CTRL + 1 .
3. To open the API documentation of the control in the Demo Kit, choose Display in Demo Kit.
1.2.9.3.2.8 Use JavaScript and XML Templates

You can add SAPUI5 control-specific templates for JavaScript code. Such templates are available, for example, in JavaScript views of SAPUI5 application
tools development.
Context
SAPUI5 provides the possibility to add SAPUI5 control specific templates for JavaScript and XML code. These templates are available, for example, in
JavaScript and XML views of SAPUI5 Application development. They are generated during startup of the Eclipse runtime.
The templates are an overview over all available
control properties
aggregations
associations and
events
To use the JavaScript and XML templates, the SAPUI5 application development tools feature has to be installed in your Eclipse.
Procedure
1. To insert a template, open the JavaScript editor.
2. Start typing the name of the respective control or the name of the alias, for example button.
3. Choose CRTL + SPACE and choose the control from the code completion list.

All properties and events are inserted.
SAPUI5 Snippets
SAPUI5 snippets are templates and examples on how to use the SAPUI5 runtime and controls.
Context
You can add SAPUI5-specific code parts, so called 1.2.9.3.2.9 SAPUI5 Snippets . SAPUI5 snippets are available as prepared HTML pages with no
separation between model, view and, controller (MVC) and they are generated during startup of the Eclipse runtime.
Procedure
1. To open the Snippets view, proceed as follows:
1. Choose Window Show View Other... .
2. In the Show View dialog, choose General Snippets and confirm you selection with OK .
The Snippet view opens.
2. To insert a snippet, proceed as follows:

1. Open the index.html of your application project in the HTML editor.

2. Delete all content.
3. To insert the snippet code, double click the snippet or use drag&drop.
4. Save the code and run it in the integrated browser.

Note
If you have problems with incorrect rendered pages, open the external browser.
Results
The page should then be displayed correctly:

1.2.9.3.2.10 Running an App in the Application Preview
You access the application preview using the Web App Preview, provided with the embedded Jetty server. You can quickly check on your application and

open it in the default browser.
Procedure
1. To test the new application with the application preview in an embedded Jetty server, right-click the HTML file or the project node and choose Run
As Web App Preview . Everything is configured automatically.
2. To refresh after having changed a file of your application, choose Refresh on the left hand side of the preview editor to refresh the preview.
3. To check the files of your application project in an external browser, choose Open in external browser on the right hand side of the preview editor. This
function opens the external browser which is specified in the Eclipse preferences under General Web Browser . This is usually the default
browser of your PC. For other external browsers, you can also copy the URL from the text field of the editor to the external browser.
Depending on the libraries you use, different browsers are supported. For more information, see: Browser and Platform Support
Open in External Browser
Note
Before deploying a application that has been created by using the Eclipse application development tool on a Java server, ensure to adapt the
web.xml file in the <WebContent folder name>/WEB-INF folder of the application by removing the mapping to the test resources. Test
resources should only be used during testing. Remove or comment the following lines:
<servlet-mapping>
<servlet-name>ResourceServlet</servlet-name>
<url-pattern>/test-resources/*</url-pattern>
</servlet-mapping>
1.2.9.3.2.10.1 Use a SimpleProxyServlet for Testing to Avoid

Cross-domain Requests
If you are testing locally in your Java Eclipse environment and you want to access an OData service in the ABAP system, a proxy is needed to ensure the
same origin policy. In an SAPUI5 application project you can use a SimpleProxyServlet for local testing.
Caution
Be aware that due to security reasons the SimpleProxyServlet is restricted to local testing purposes only. It can only be used for local host scenarios
(accessing Gateway services to avoid cross-domain issues) and will not work when deployed on an application server. For productive use, refer to a
mature proxy servlet.
Note
If you have issues with accessing HTTPS systems via the ResourceServlet or the SimpleProxyServlet it may be necessary to import the root
certificate into the Java keystore.
.
Ideally, all OData service URLs should be in one file to make the exchange easier - either in the index.html, or in one separate .js file which needs to be
included. The application is responsible for exchanging the URLs before checking in and after checking out to SAPUI5 Repository. You can also use the helper
function getServiceUrl for which also the application is responsible. See the following example:
<script>
//var serviceUrl = "/mypath/myservice"; //url when running on the ABAP system
//var serviceUrl = "proxy/mypath/myservice"; //url when running locally in Eclipse
var serviceUrl = getServiceUrl("/mypath/myservice");
function getServiceUrl(sServiceUrl) {
//for local testing prefix with proxy
//if you and your team use a special host name or IP like 127.0.0.1 for localhost please adapt the if statement below
if (window.location.hostname == "localhost") {
return "proxy" + sServiceUrl;
} else {
return sServiceUrl;

}
}
</script>
As parameter for the getServiceUrl helper method, use the URL of the OData service document without {protocol}://{host name}:{port number}, for
example: /mypath/myservice.
Note
Place the script tag before the script that calls the view (sap.ui.view).
Intranet Servers
The SimpleProxyServlet allows proxy requests to an arbitrary server in the intranet.
The proxy URL that is used in the coding looks like this: proxy/<service url>.
Open the web.xml file located in the <WebContent folder name>/WEB-INF folder and configure the parameter
com.sap.ui5.proxy.REMOTE_LOCATION of the SimpleProxyServlet where the placeholders {protocol}, {host name}, {port number} are to be exchanged by
the real protocol, host name and port number:
<servlet>
<servlet-name>SimpleProxyServlet</servlet-name>
<servlet-class>com.sap.ui5.proxy.SimpleProxyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>SimpleProxyServlet</servlet-name>
<url-pattern>/proxy/*</url-pattern>
</servlet-mapping>
<context-param>
<param-name>com.sap.ui5.proxy.REMOTE_LOCATION</param-name>
<param-value>{protocol}://{host name}:{port number}</param-value>
</context-param>
Internet Servers
The SimpleProxyServlet can be configured for proxy requests to internet servers in the same way as for intranet servers. Additional proxy settings may
be necessary.
As the SimpleProxyServlet automatically uses the proxy settings from your Eclipse this can be configured in Eclipse under Window Preferences
, and select General Network Connections . Here you can specify the proxy entries and the proxy bypass.
For example, set Active Provider to Manual, Schema=HTTP, Host=proxy, Port=8080 under proxy entries and localhost, *.mycompany.corp as Host under
proxy bypass.
Simple Proxy Servlet - Restriction Regarding DELETE Requests

The simple proxy servlet currently does not support the sending of HTTP DELETE requests with content. This is due to restrictions of the Java SE
functionality that is used. If an HTTP DELETE request with content is sent, an HTTP 500 result status is sent with the description: "The HttpUrlConnection
used by the SimpleProxyServlet doesn't allow to send content with the HTTP method DELETE. Due to spec having content for DELETE methods is possible
but the default implementation of the HttpUrlConnection doesn't allow this!"
For practical purposes, this restriction should have only minor effects. This is because:
When applying a REST-like programming style, an HTTP DELETE request would use the URL to transmit which objects should be deleted, but not the
content.
When building your own protocol that uses the content of the HTTP request, you typically use HTTP POST.
Node.js-Based Development Environment

Used for modifying OpenUI5. The environment is based on Node.js, used as a server, with a build process that is based on Grunt. This section provides
information for the initial setup, development roundtrip, and tests execution.
The Regular Development Process

No build process is required, you can simply modify any source file and reload your browser.
This build-free development process does not deliver optimized runtime performance (for example, there are many small requests, which would not be
acceptable for remote connections). There are mainly two mechanisms applied that adapt the sources:
The Git repository path contains a folder with the same name as the respective control library (for example, sap.ui.commons), which is omitted at
runtime. The Node.js-based server is configured to map the locations.
The CSS files are transformed (server-side) by the LESS preprocessor during the first request after a CSS file has been modified. This includes mirroring
for right-to-left support. After a CSS modification, this first request to the respective library.css file will take several hundred milliseconds,
depending on the amount of CSS involved. This is the LESS processing time.
Building SAPUI5
Grunt is used to build a production version of SAPUI5. The build result is located inside the directory target/openui5.

Usage: grunt build
Optionally, you can choose to build selected libraries only or skip copying the test-resources folder.
Caution
As the build infrastructure is still being migrated from the old Maven-based one, the Grunt build does not yet have all desired capabilities. This means that
the build result is not currently completely optimized for size and performance. If you intend to use SAPUI5 for productive purposes, we recommend using
the runtime binaries provided at http://openui5.org .
The build process is responsible for the following tasks:

Creation of the bundled library.css and library-RTL.css file for all available themes
Minification of CSS
Minification of JavaScript (for library-preload.json files)
Combination of JavaScript control files into a single library-preload.json file
Combination of the most important SAPUI5 core files into sap-ui-core.js (not yet optimized; minification missing)
In this section:
Installing the 1.2.9.4 Node.js-Based Development Environment
Installation steps for Node.js
Testing SAPUI5
Test your development using ESLint or unit tests.
Common Installation Issues
Common installation issues that you might face when using the node.js based development environment
Installing the Node.js-Based Development Environment

Installation steps for Node.js
1. Download Node.js from http://nodejs.org and install it.
Note
The installation includes the Node Package Manager (npm).
2. Set the environment variables in the operating system settings or in the command line. You need to do this if you are working behind an HTTP proxy:
@SET HTTP_PROXY=http://proxy:8080
@SET HTTPS_PROXY=http://proxy:8080
@SET FTP_PROXY=http://proxy:8080
@SET NO_PROXY=localhost,127.0.0.1,.mycompany.corp
Note
The example shown above is for the Windows command line. You may have to adapt the settings according to your specific proxy configuration.
3. Install the Grunt command line interface (grunt-cli) globally with the following command: npm install grunt-cli -g.
4. Download and install Git from http://git-scm.com/download .
5. Clone the Git repository with the following command git clone https://github.com/SAP/openui5.git.
6. Install all npm dependencies locally. Execute the commands inside the openui5 directory as show below:
cd openui5
npm install
7. Start the server: with grunt serve.
Note
grunt serve has various configuration options you can use. For example, you can specify the parameter --port=9090 to use a different HTTP
port.
8. Point your browser to the following server where SAPUI5 is running: http://localhost:8080/testsuite/.
Testing SAPUI5
Test your development using ESLint or unit tests.
Running Static Code Checks (ESLint)

All SAPUI5 code must conform to a certain ruleset which is checked using a tool called ESLint (see Related Information for more details).
To run an ESLint check, navigate to the root directory of the repository and execute:
grunt lint
Optionally, you can check a selected library only or even just a single file or directory.
Running the Unit Tests

The SAPUI5 unit tests are implemented using jQuery's qUnit testing framework and run by a Selenium-based infrastructure.
To execute the unit tests, navigate to the root directory of the repository and execute:
grunt test

Caution
By default, this command runs tests for all libraries in the Google Chrome browser. For all browsers except for Mozilla Firefox, additional Selenium web
drivers need to be installed.
You can change this default behavior by specifying the following parameters:
grunt test --browsers="safari,firefox" # run tests of all libraries on Safari and Firefox
Related Information
http://eslint.org
Common Installation Issues

Common installation issues that you might face when using the node.js based development environment
Updating the build tools (task "replace:target" not found)

If you encounter errors like the one below, execute the npm install command again: there may be new build tools required that need to be downloaded first.
jit-grunt: Plugin for the "replace" task not found.
If you have installed the plugin already, please setting the static mapping.
See https://github.com/shootaroo/jit-grunt#static-mappings
Warning: Task "replace:target" not found. Use --force to continue.
Proxy issues
grunt test will download the selenium-server-standalone.jar file when run for the first time. If you are working behind a proxy and have no
environment variables set for the proxy, this will fail when run for the first time:
selenium-server-standalone.jar not found. Downloading...
>> Error: getaddrinfo ENOTFOUND
To solve this issue, set the environment variables for the proxy server.For more information, see Installing the Node.js-Based Development Environment.
"Browser not found" issues

Selenium needs to find the browser executable on the PATH, otherwise you will see the following error message:
firefox
Fatal error: Cannot find firefox binary in PATH. Make sure firefox is installed.
To solve this issue, add the Firefox installation folder to the PATH environment variable.
"Path to the driver executable" issues with browsers other than Mozilla Firefox
If you get the following error, remember that you need to install extra Selenium Web Drivers for all browsers apart from Mozilla Firefox:
Fatal error: The path to the driver executable must be set by the webdriver.chrome.driver system property;
for more information, see http://code.google.com/p/selenium/wiki/ChromeDriver.
The latest version can be downloaded from http://chromedriver.storage.googleapis.com/index.html
To solve this issue, download the Selenium driver for the respective browser and make sure the Selenium Web Driver finds it. See the table below for specific
browser instructions.
Browser Details
Google Chrome 1. Download the current chromedriver_*.zip from

http://chromedriver.storage.googleapis.com/index.htm
2. Extract the executable to a suitable location (for example, C:\Program
Files (x86)\Selenium Drivers)
3. Include the ChromeDriver location in your PATH environment variable
Internet Explorer (browser type "ie") Download the driver from the following location: http://selenium-
release.storage.googleapis.com/index.html
Note
You may have to adjust the Protected Mode settings on the Security tab
under Internet options .
Other browsers Consult their respective driver documentation.
Undeletable folders
If you encounter source folders that cannot be deleted because a process is locking them, one possible cause may be the Google Chrome or Internet Explorer
web drivers. Check whether they are among the active processes.
1.2.9.5 Development for Hybrid Web Containers

You can develop mobile apps as hybrid app consisting of a native app wrapper, for example PhoneGap, and an HTML viewer to display the content on the
user interface.
Hybrid apps have the advantage that you can publish them in app stores. Also, by embedding the application code in hybrid apps and the library files in the
hybrid container, the user needs to install the files only once and does not need to download them every time he starts the application. But then the library
size becomes important, because every user has to install the files, whereas in web applications the library is deployed on a server and the user only needs to
download the required parts of the library at runtime.
To include the resources you need in your hybrid app, you can use the static mobile runtime package openui5-runtime-mobile*.zip. The package is
not contained in SAPUI5, but in the Open Source version OpenUI5.
The library size of these packages is rather small because the content that is most likely not needed has been removed, for example test pages. A package
contains the debug version of all JavaScript files and the optimized and minimized version. Thus, you can use the package for productive use as well as for
debugging purposes. To use this package in an app wrapper, such as PhoneGap, unzip the package in the respective resource location of the app
development project. The app wrapper build then includes the files and makes them available at runtime.
To ensure that the file is small, it only contains the control libraries that are most likely used and not all control libraries. Depending on the hybrid app it may be
necessary to add libraries by copying them from the respective folder of the runtime, or to delete libraries to reduce the package size and, thus, also reduce
the installation size for the user.
The file contains the following control libraries:
sap.m
sap.tnt
sap.ui.core
sap.ui.dt
sap.ui.layout
sap.ui.suite
sap.ui.unified
sap.uxap
The decision, which libraries to include or not may be disputed. It is only based on a rule of thumb, and adaptations are required anyway for many apps.
Also, the mobile/hybrid package excludes certain types of files which are typically not needed. Your mileage may vary, so you might need to add the
respective files for the requirements of your specific app. The library-preload.json files which contain all controls from a library to reduce the number of
HTTP requests are not required in hybrid apps because there is no HTTP latency. SAPUI5 will by default try to access them, so you might see a failed
attempt to load these files in the log file or developer tools. These error messages do not hurt, though, and you can get rid of them by declaring that no such
files exist and by setting the following configuration in the SAPUI5 bootstrap script tag:
data-sap-ui-preload=""
Optimization of the Package Size

Although the static package is small enough to be included in hybrid apps, you can reduce the size further and optimize the content for a specific application
by deleting additional files. The following list gives some examples:
You can delete one of the following files from the /resources folder depending on your setup: sap-ui-core-nojQuery.js if you reference
SAPUI5 normally or sap-ui-core.js if you reference the nojQuery version and reference the jQuery version separately, for example if you run in
a Sybase hybrid container.
You can delete all library folders if the respective control library is not needed. If you do not use charts, you can delete the complete makit and viz
folder in /resources/sap. And in the OpenUI5 version you can, for example, delete the suite and the unified folder if you do not need them.
If you use the sap-ui-core.js file for bootstrap, you can delete the jquery and jqueryui folders in /resources/sap/ui/thirdparty. These
files may be needed when you use the sap-ui-core-nojQuery.js script, but if you have another copy of jQuery available you can still delete the
folder.
Depending on the theme you use, you can delete the base and either the sap_bluecrystal or the sap_mvi folders in each of the
/resources/sap/* ... */themes folders.
Note
For all JavaScript files, an optimized version and a debug (dbg) version exists. If you delete the files, make sure that you always delete both versions. If
you can do without easy debugging and want to achieve a minimum installation size instead, you can delete all *-dbg.js files.
You can delete further files, but the size reduction is limited and to find out the files that are not required gets increasingly difficult.
Device Ready Event

The hybrid web container needs some time for initialization. During this time, the sending of AJAX requests is blocked, meaning that JavaScript code stops
once an AJAX request is sent and the code execution stops as well. This leads to a UI freeze effect.
The oData model in SAPUI5 uses AJAX requests internally and the oData model initialization must therefore be done after the hybrid container is ready to
avoid a user interface freeze. After initialization, the hybrid web containers fires an event, which is called deviceready in PhoneGap. To fix this issue, move
the code where the oData model is created and set to the core object or any other controls' model property to the deviceready event listener.
Example:
<script>

function appReady(){
sap.ui.getCore().setModel(new sap.ui.model.odata.ODataModel(<ODATA_URL>, false));
}

document.addEventListener("deviceready", appReady, false);
</script>
Cross Domain Restrictions

Cross Domain Restrictions
If you load data from an external server or service using AJAX, the external domain has to be configured inside the hybrid web container to make the AJAX
request go through the cross domain restriction. The following findings result from an integration of the demo applications into PhoneGap:
Android
If the AJAX code runs inside the webview in Android, no cross domain restriction exists. This means that you can load data using AJAX from
everywhere. The PhoneGap documentation, however, still says that the domain needs to be configured in one XML file.
iOS
The restriction in webview in iOS still exists and you need to add the domain that is visited using AJAX to a whitelist file to bypass the restriction. For
detailed information about the whitelist file, see the PhoneGap documentation on the PhoneGap website.
SAPUI5 Runtime Installation (SAP NetWeaver 7.3 EHP1 or Lower)

Installation prerequisites and installation process for SAPUI5 Runtime
If you are using SAP NetWeaver 7.3 EHP1 or lower, you need to install the SAPUI5 Runtime for developing SAPUI5 apps.
Required Software Components for SAPUI5 Runtime

Before you start the installation of SAPUI5 Runtime, download the respective software components from the SAP Software Download Center on SAP Service
Marketplace at http://service.sap.com/swdc .
1.3 Tutorials
The SAPUI5 tutorials introduce you to all major development paradigms of SAPUI5 using practical examples in an interactive format.
Each tutorial has a different focus and guides you through the major topics of SAPUI5, helping you learn best practices for building apps with SAPUI5. The
detailed documentation described here can be used in combination with downloadable code in the Explored app in the Demo Kit.
You can use your preferred development environment to go through the steps of each tutorial. Each step explains a specific feature or aspect of SAPUI5 by
way of small incremental changes. The code that is added in each step is highlighted in the code blocks and followed by a detailed explanation.
Note
The apps that we build throughout these tutorials might simplify some aspects of real app development in order to focus on the plot line. (We admit that in
some places, the UI might seem silly or unrealistic.) Please refer to the rest of the SAPUI5 documentation to dive deeper into the various topics,
especially those described under Developing Apps and Essentials.
Learning Path
If you only want a first insight featuring the very basics, try the short Hello World tutorial.
If you are new to SAPUI5 or would like to get a refresher on the latest best practices, start with the Walkthrough .
After that, you can proceed with the other tutorials that build up on that knowledge and go into more detail on specific topics like data binding, navigation and
routing, using smart controls.
Prerequisites
You should be familiar with JavaScript.
Set up your development environment.
You can use any development environment or IDE of your choice that is suitable for Web development. If you dont know which development
environment to use, we recommend trying the SAP Web IDE. It is a cloud-based development environment optimized for SAPUI5 app development and
includes a cloud runtime to test the app.
For more information on how to set up your development environment, see Development Environment.
Set up a (local) Web server to run the app that is being built throughout this tutorial. (In SAP Web IDE, this is already included).

Get SAPUI5 and place it in a location, which can be accessed in the resources folder (not necessary for SAP Web IDE).
Set up a folder where you would place the application content. We will refer to this folder as the app folder.
Familiarize yourself with the debugging tools of the browser and SAPUI5 in case you get stuck.
Outline of the Steps of Each Tutorial

There are two different tutorial formats: Some tutorials start with an empty project and let you develop the whole app step by step, others start with an initial
project in the first step that you can download from the Explored app in the Demo Kit. You use the code from this initial project as a starting point for the
subsequent tutorial steps.
Each step of the tutorial starts with a preview of the user interface (UI) which shows how it will look like after the step is accomplished.
It then displays the files that have to be changed in the step, highlighting the changed code, along with an explanation of the entire process.
You can view and download the files for all steps in the Explored app in the Demo Kit. The Explored app always contain the latest version of the sample
code. So if you find differences to the coding in the step description, follow the version in Explored . Depending on your development environment you might
have to adjust resource paths and configuration entries.
It also mentions the recommended conventions that should be adhered to, and contains links to related documentation.
Tip
You don't have to do all tutorial steps sequentially, you can also jump directly to any step you want. Just download the code from the previous step, copy
it to your workspace and make sure that the application runs by calling the webapp/index.html file.
Downloading Code for a Tutorial Step

To download the code from the Explored app in the Demo Kit, follow these steps:
1. Choose the link in the Coding section of the current tutorial step or open the sample in the Explored app directly.
2. Choose the icon with the Show source code for this sample tooltip in the right-hand part of the header bar to display all files included in this sample.
3. Choose the Download button. A download.zip file is downloaded to your local machine.
4. Extract or upload the zip file to your development environment and adjust the project configuration files to match your development environment.
Test the project by calling one of the HTML pages in your development environment and make sure that the app is displaying the features exactly as
shown in the preview of the step.
Adapting Code to Your Development Environment

You might have to adapt parts of the coding to your local development environment to make the app work. Please check the following settings carefully:
Project Path and Deployment
All tutorials assume that the app is deployed and can be accessed under a certain path on a Web server. You will not be able to run the app without a
Web server as the browser does not allow you to load the required resources locally due to security restrictions.
Depending on your server configuration and deployment mode, you will either have to include or exclude the webapp folder in your URL path. If you
choose to deploy the app to another path, you will have to adapt the file paths and URLs accordingly.
SAPUI5 Resources
You can either download and deploy the runtime to your (local) Web server or reference the CDN version located at
https://sapui5.hana.ondemand.com/resources/sap-ui-core.js. Some development environments such as the SAP Web IDE also
provide a local runtime for testing purposes. If you download the code from the samples in the Explored app, you will have to adapt the resource path
in the bootstrap section of all HTML pages included in the project. In the tutorial code, we assume that SAPUI5 can be accessed from the
/resources path of the server.
Accessing Remote Services
Browsers typically prevent accessing remote resources due to the Cross-Origin Resource Sharing (CORS) policy. If you would like to call a real service
or remote resources, you will have to either configure the development environment or the remote server to accept these requests. This strongly
depends on the development environment and is described in more detail below.
Troubleshooting
If you get stuck on a certain tutorial step, please have a look at the developer console of your browser. Are there log messages displayed related to the error?
Did it work before, and your recent change broke the app? Try reverting the previous change and test if the app can be run again. The most common errors are
as follows:
Error message sap is not defined in the console and the page stays blank
Have a look at the resource path in the bootstrap of the HTML page you are trying to open. The path to the file sap-ui-core.js is probably
incorrect and needs to point to the path where the SAPUI5 resources are located (typically globally under /resources or locally under resources).
Note
If you are running the tutorial in SAP Web IDE, you will have to configure the project descriptor neo-app.json. In this descriptor file, the path to
the resources is already configured. Other development environments might need the resources to be copied to the server. Alternatively, you can
use the CDN version of https://sapui5.hana.ondemand.com/resources/sap-ui-core.js.
No texts from the resource bundle are displayed in the app

You are running the tutorial with an outdated version of SAPUI5. Most tutorials need to be run with SAPUI5 version 1.30 or higher, because the models
are instantiated by the manifest.json descriptor file. This feature is not available in release 1.28 and thus the models will not be loaded. As a
workaround, you can instantiate the models manually in the init method of the app component.
No model data in the application when trying to access a real service
Modern browsers prevent calling files and services from another server due to security restrictions. When accessing a remote service, you configure
your application project or the remote server accordingly. Otherwise you will get a log message telling you that Cross-Origin Resource Sharing (CORS) is
not configured and calling the remote URL is not allowed.

Note
The configuration for calling remote services strongly depends on your development environment. All tutorials can be called with local test data
instead if you are having trouble accessing a real service. Typically, the HTML page for running the app with local test data is called
testService.html and located in the test folder of the app.
If these hints still don't help fix the problem in your app project, try downloading the solution of the current step or the next step of the tutorial from the
Explored app. This should get your project fixed again, just dont forget to check the resource path and the project configuration files again.
Please also check the generic troubleshooting section here: Troubleshooting.
1.3.1 Hello World!

With this tutorial, you learn how to create a simple first app in a few steps on a single HTML page.
We create an app with two pages and a navigation button to navigate between the pages.
Preview
Figure 1: Simple "Hello World" App - First Page
Figure 2: Simple "Hello World" App - Second Page
Note
You can view the demo app in the Demo Kit under Demo Apps .
Coding
In the following steps, we will create an index.html file with the code below. If you directly want to try the app, just copy and paste the code from here.
You can also launch this mini application and modify the code by creating a jsbin example at https://jsbin.com .
Caution
Adapt the path where the resources are located (< <server> >:< <port> >) according to your installation. For OpenUI5 you can use
src="https://openui5.hana.ondemand.com/resources/sap-ui-core.js". For accessing SAPUI5 on the SAP HANA Cloud Platform, for
example, use src="https://sapui5.hana.ondemand.com/resources/sap-ui-core.js".
You can use this reference to the latest stable version of SAPUI5 for the tutorial or for testing purposes, but never use this for productive use. In an actual
app, you always have to specify an SAPUI5 version explicitly.
For more information, see Step 1: Create an HTML Page and Variant for Bootstrapping from Content Delivery Network.
<!DOCTYPE html>
<html>
<head>
<title>Hello World App</title>
<script src="http://< <server> >:< <port> >/resources/sap-ui-core.js"
data-sap-ui-libs="sap.m">
</script>
<script type="text/javascript">
// create a mobile app and display page1 initially
var app = new sap.m.App("myApp", {
initialPage: "page1"
});
// create the first page
var page1 = new sap.m.Page("page1", {

title : "Hello World",
showNavButton : false,
content : new sap.m.Button({
text : "Go to Page 2",
press : function () {
// navigate to page2
app.to("page2");
}
})
});
// create the second page with a back button
title : "Hello Page 2",
showNavButton : true,
navButtonPress : function () {
// go back to the previous page
app.back();
}
});
// add both pages to the app
app.addPage(page1).addPage(page2);
// place the app into the HTML document
app.placeAt("content");
});
</script>
</head>
</body>
</html>
1. Step 1: Create an HTML Page
We start with creating an HTML page for the app. There we define the meta tags, a script tag to load the SAPUI5 libraries, and a placeholder for the
content of the app.
2. Step 2: Initialize the App
The sap.m library provides a control called App which is meant to be the root control of an app. It initializes the content of the body tag, sets some
meta tags on the HTML document for mobile devices, and can manage multiple pages and the animations when navigating.
3. Step 3: Add Content Pages
Apps consist of a set of pages, views, and screens between which the user can navigate. Now we add two pages to the app.
4. Summary
We have now created our "Hello World" app with two pages in only one HTML file.
1.3.1.1 Step 1: Create an HTML Page

We start with creating an HTML page for the app. There we define the meta tags, a script tag to load the SAPUI5 libraries, and a placeholder for the content of
the app.
index.html (new)
<!DOCTYPE html>
<html>
<head>
<script src="http://< <server> >:< <port> >/resources/sap-ui-core.js"
</script>
</head>
</body>
</html>
Create a file named index.html and add following sections:
<!DOCTYPE html>: This line tells the browser that this page is written in HTML5.
head with the following information:
The meta tags <meta http-equiv="X-UA-Compatible" content="IE=edge"> to tell Microsoft Internet Explorer to use the latest
rendering engine (edge) and <meta charset="utf-8"> to tell any browser that this file is UTF-8 encoded (assuming that you use this
encoding when editing or saving the file).
The title text.
The script tag to load and initialize SAPUI5 with the following information:
Location of the resources
Caution
Adapt the path where the resources are located (< <server> >:< <port> >) according to your installation. For OpenUI5 you can use
src="https://openui5.hana.ondemand.com/resources/sap-ui-core.js". For accessing SAPUI5 on the SAP HANA
Cloud Platform, for example, use src="https://sapui5.hana.ondemand.com/resources/sap-ui-core.js".

You can use this reference to the latest stable version of SAPUI5 for the tutorial or for testing purposes, but never use this for productive
use. In an actual app, you always have to specify an SAPUI5 version explicitly.
For more information, see Variant for Bootstrapping from Content Delivery Network.
You define which library is loaded, and which theme should be used. In our example, only the sap.m library and the sap_bluecrystal theme
are loaded. You can load additional libraries and themes if you like.
Note
Refer to the documentation linked below for further initialization options.
The HTML <body> tag the with ID content and class sapUiBody. This is where the content of the app will be added in in the next steps
Now, SAPUI5 including controls is loaded and ready to use.
Parent topic: Hello World!
Next: Step 2: Initialize the App
Related Information
Bootstrapping: Loading and Initializing
Initialization Process
1.3.1.2 Step 2: Initialize the App

The sap.m library provides a control called App which is meant to be the root control of an app. It initializes the content of the body tag, sets some meta
tags on the HTML document for mobile devices, and can manage multiple pages and the animations when navigating.
index.html
<!DOCTYPE html>
<html>
<head>
<script src="http://<server>:<port>/resources/sap-ui-core.js"
</script>
});
});
</script>
</head>
</body>
</html>
In a second script block, we attach a function to the global attachInit event. This function will be called as soon as SAPUI5 is loaded and initialized.
Create the app control here, and define the page that you want be displayed initially. At this point in time, this page does not have any content.
Instead of using the sap.m.App control, you could also manually call the methodjQuery.sap.initMobile() to set up the HTML and use other full
screen controls, such as sap.m.Page or sap.m.Carousel as root element of your app.
Previous: Step 1: Create an HTML Page
Next: Step 3: Add Content Pages
1.3.1.3 Step 3: Add Content Pages

Apps consist of a set of pages, views, and screens between which the user can navigate. Now we add two pages to the app.
index.html
<!DOCTYPE html>
<html>
<head>

<script src="http://<server>:<port>/resources/sap-ui-core.js"
</script>
});
// create the first page
title : "Hello World",
showNavButton : false,
content : new sap.m.Button({
text : "Go to Page 2",
press : function () {
// navigate to page2
app.to("page2");
}
})
});
// create the second page with a back button
title : "Hello Page 2",
showNavButton : true,
navButtonPress : function () {
// go back to the previous page
app.back();
}
});
// add both pages to the app
// place the app into the HTML document
});
</script>
</head>
</body>
</html>
1. Create one sap.m.Page control and set its title. To keep this example simple, the content is just one button that navigates to the second page by
calling app.to("page2") when the button is pressed. The parameter page2 is the ID of the second page. You could also specify the animation
type for the navigation. The default is a slide animation from right to left.
Note
sap.m.Page controls can be used for the aggregation pages of the app control, but other controls could be used as well. The page has a
scrollable content section for displaying information and will create a header and an optional footer area.
2. Create the second page that displays the Back button. The property showNavButton is set to true to display a Back button. When it is pressed,
the event handler function calls app.back(). This will bring the user back to the main page with an an inverse animation.
3. Add both pages to the app and place the app in the content area of the HTML file that you have defined as the body tag earlier:
The app is now placed into the HTML, the app uses the whole screen size that is available on the device.
Previous: Step 2: Initialize the App
Next: Summary
1.3.4.18 Summary
We have now created our "Hello World" app with two pages in only one HTML file.
You can run the app in any browser on any device.
For using the app on a mobile device, you upload the HTML file to a Web server and call the resulting URL in your mobile browser.
Test the navigation between both pages by choosing the buttons.
Previous: Step 3: Add Content Pages
1.3.2 Walkthrough
1.3.2 Walkthrough
In this tutorial we will introduce you to all major development paradigms of SAPUI5.
Despite the simplicity of the UI, we strive for a proper setup of modules, structuring of application code and adherence to code conventions. As such this
tutorial represents a best practice for building apps with SAPUI5.
The UI might be a bit inconsistent in some places dont take it as a UI design guideline. We'll show you around using minimal code changes in each step.
Caution
Some steps of this tutorial use features that are only available as of SAPUI5 version 1.30. If you use a lower version of the library you might not be able to
see the expected result. Whenever suitable, we point out alternatives for lower releases.
We first introduce you to the basic development paradigms like Model-View-Controller and establish the basic structure of our application. We'll do this along
the classic example of Hello World and start a new app from scratch. Next, we'll introduce the fundamental data binding concepts of SAPUI5 and extend our
app to show a list of invoices. We'll continue to add more functionality by adding navigation, extending controls, and making our app responsive.Finally we'll
look at the testing features and the built-in support tools of SAPUI5.
Preview
Tip
You can view and download the files for all steps in the Explored app in the demo kit under Walkthrough . Depending on your development environment
you might have to adjust resource paths and configuration entries.
For more information check the following sections of the tutorials overview page (see Tutorials):
Prerequisites
Troubleshooting
1. Step 1: Hello World!

As you know SAPUI5 is all about HTML5. Lets get started with building a first Hello World with only HTML.
2. Step 2: Bootstrap
Before we can do something with SAPUI5, we need to load and initialize it. This process of loading and initializing SAPUI5 is called bootstrapping.
Once this bootstrapping is finished, we simply display an alert.
3. Step 3: Controls
Now it is time to build our first little UI by replacing the Hello World text in the HTML body by the SAPUI5 control sap.m.Text. In the beginning, we
will use the JavaScript control interface to set up the UI, the control instance is then placed into the HTML body.
4. Step 4: XML Views
Putting all our UI into the index.html file will very soon result in a messy setup and there is quite a bit of work ahead of us. So lets do a first
modularization by putting the sap.m.Text control into a dedicated view. SAPUI5 supports multiple view types (XML, HTML, JavaScript). We choose
XML as this produces the most readable code and will force us to separate the view declaration from the controller logic. Yet the look of our UI will not
change.
5. Step 5: Controllers

In this step, we replace the text with a button and show the Hello World message when the button is pressed. The handling of the button's press event
is implemented in the controller of the view.
6. Step 6: Modules
In SAPUI5, resources are often referred to as "modules". In this step, we replace the alert from the last exercise with a proper "Message Toast" from the
sap.m library. The required modules are enabled to be loaded asynchronously.
7. Step 7: JSON Model
Now that we have set up the view and controller, its about time to think about the "M" in MVC. We will add an input field to our app, bind its value to the
model, and bind the same value to the description of the input field. The description will be directly updated as the user types.
8. Step 8: Translatable Texts
In this step we move the texts of our UI to a separate resource file. This way, they are all in a central place and can be easily translated into other
languages. This process of internationalization in short i18n is achieved in SAPUI5 by using a special resource model and the standard data
binding syntax, but without preceding /.
9. Step 9: Component Configuration
After we have introduced all three parts of the Model-View-Controller (MVC) concept, we now come to another important structural aspect of SAPUI5. In
this step, we will encapsulate all UI assets in a component that is independent from our index.html file. Components are independent and reusable
parts used in SAPUI5 applications. Whenever we access resources, we will now do this relatively to the component (instead of relatively to the
index.html). This architectural change allows our app to be used in more flexible environments than our static index.html page, such as in a
surrounding container like the SAP Fiori launchpad.
10. Step 10: Descriptor for Applications
All application-specific configuration settings will now further be put in a separate descriptor file called manifest.json. This clearly separates the
application coding from the configuration settings and makes our app even more flexible. For example, all SAP Fiori applications are realized as
components and come with a descriptor file in order to be hosted in the SAP Fiori launchpad.
11. Step 11: Pages and Panels
After all the work on the app structure its time to improve the look of our app. We will use two controls from the sap.m library to add a bit more "bling"
to our UI. You will also learn about control aggregations in this step.
12. Step 12: Shell Control as Container
Now we use a shell control as container for our app and use it as our new root element. The shell takes care of visual adaptation of the application to the
devices screen size by introducing a so-called letterbox on desktop screens.
13. Step 13: Margins and Paddings
Our app content is still glued to the corners of the letterbox. To fine-tune our layout, we can add margins and paddings to the controls that we added in
the previous step. But instead of manually adding CSS to the controls, we will use the standard classes provided by SAPUI5. These classes take care
of consistent sizing steps, left-to-right support, and responsiveness.
14. Step 14: Custom CSS and Theme Colors
Sometimes we need to define some more fine-granular layouts and this is when we can use the flexibility of CSS by adding custom style classes to
controls and style them as we like.
15. Step 15: Nested Views
Our panel content is getting more and more complex and now it is time to move the panel content to a separate view. With that approach, the application
structure is much easier to understand, and the individual parts of the app can be reused.
16. Step 16: Dialogs and Fragments
In this step, we will take a closer look at another element which can be used to assemble views: the fragment.
17. Step 17: Fragment Callbacks
Now that we have integrated the dialog, it's time to add some user interaction. The user will definitely want to close the dialog again at some point, so we
add a button to close the dialog and assign an event handler.
18. Step 18: Icons
Our dialog is still pretty much empty. Since SAPUI5 is shipped with a large icon font that contains more than 500 icons, we will add an icon to greet our
users when the dialog is opened.
19. Step 19: Reuse Dialogs
In step 16 we created a dialog as fragment, because we wanted it to be reusable across views or across our whole app. But we placed the logic for
retrieving the dialog instance and for opening and closing it respectively in the controller of the HelloPanel view. Sticking to this approach would
require copying and pasting the code to the controller of each view that needs our dialog. This would of course cause an undesired code redundancy we
definitely want to avoid. In this step, we will implement the solution to this problem: We now expand our reuse concept and invoke the dialog at
component level.
20. Step 20: Aggregation Binding
Now that we have established a good structure for our app, it's time to add some more functionality. We start exploring more features of data binding by
adding some invoice data in JSON format that we display in a list below the panel.
21. Step 21: Data Types
The list of invoices is already looking nice, but what is an invoice without a price assigned? Typically prices are stored in a technical format and with a
'.' delimiter in the data model. For example, our invoice for pineapples has the calculated price 87.2 without a currency. We are going to use the
SAPUI5 data types to format the price properly, with a locale-dependent decimal separator and two digits after the separator.
22. Step 22: Expression Binding
Sometimes the predefined types of SAPUI5 are not flexible enough and you want to do a simple calculation or formatting in the view - that is where
expressions are really helpful. We use them to format our price according to the current number in the data model.
23. Step 23: Custom Formatters
If we want to do a more complex logic for formatting properties of our data model, we can also write a custom formatting function. We will now add a
localized status with a custom formatter, because the status in our data model is in a rather technical format.
24. Step 24: Filtering
In this step, we add a search field for our product list and define a filter that represents the search term. When searching, the list is automatically
updated to show only the items that match the search term.
25. Step 25: Sorting and Grouping
To make our list of invoices even more user-friendly, we sort it alphabetically instead of just showing the order from the data model. Additionally, we
introduce groups and add the company that ships the products so that the data is easier to consume.
26. Step 26: Remote OData Service
So far we have only worked with local JSON data, but now we will access a real OData service. Instead of implementing an own OData service we will
simply use the publicly available Northwind OData service to visualize remote data. You will be surprised how little needs to be changed in order to make
this work!
27. Step 27: Mock Server Configuration
We just ran our app against a real service, but for developing and testing our app we do not want to rely on the availability of the real service or put
additional load on the system where the data service is located. This system is the so-called back-end system that we will now simulate with a SAPUI5

feature called mock server. It serves local files, but it simulates a back-end system more realistically than just loading the local data. We will also
change the model instantiation part so that the model is configured in the descriptor and instantiated automatically by SAPUI5. This way, we do not need
to take care of the model instantiation in the code.
28. Step 28: Unit Test with QUnit
Now that we have a test folder in the app, we can start to increase our test coverage. Actually, every feature that we added to the app so far, would
require a separate test case. We have totally neglected this so far, so lets add a simple unit test for our custom formatter function from Step 23. We will
test if the long text for our status is correct by comparing it with the texts from our resource bundle.
29. Step 29: Integration Test with OPA
If we want to test interaction patterns or more visual features of our app, we can also write an integration test. We havent thought about testing our
interaction with the app yet, so in this step we will check if the dialog actually opens when we click the Say Hello with Dialog button. We can easily do
this with OPA5, a feature of SAPUI5 that is easy to set up and is based on JavaScript and QUnit. Using integration and unit tests and running them
consistently in a continuous integration (CI) environment, we can make sure that we dont accidentally break our app or introduce logical errors in
existing code.
30. Step 30: Debugging Tools
Even though we have added a basic test coverage in the previous steps, it seems like we accidentally broke our app, because it does not display prices
to our invoices anymore. We need to debug the issue and fix it before someone finds out. Luckily, SAPUI5 provides a couple of debugging tools that we
can use within the app to check the application logic and the developer tools of modern browsers are also quite good. We will now check for the root
cause.
31. Step 31: Routing and Navigation
So far, we have put all app content on one single page. As we add more and more features, we want to split the content and put it on separate pages. In
this step, we will use the SAPUI5 navigation features to load and show a separate detail page that we can later use to display details for an invoice. In
the previous steps, we defined the page directly in the app view so that it is displayed when the app is loaded. We will now use the SAPUI5 router class
to load the pages and update the URL for us automatically. We specify a routing configuration for our app and create a separate view for each page of
the app, then we connect the views by triggering navigation events
32. Step 32: Routing with Parameters
We can now navigate between the overview and the detail page, but the actual item that we selected in the overview is not displayed on the detail page
yet. A typical use case for our app is to show additional information for the selected item on the detail page. To make this work, we have to pass over
the information which item has been selected to the detail page and show the details for the item there.
33. Step 33: Routing Back and History
Now we can navigate to our detail page and display an invoice, but we cannot go back to the overview page yet. We'll add a back button to the detail
page and implement a function that shows our overview page again.
34. Step 34: Custom Controls
In this step, we are going to extend the functionality of SAPUI5 with a custom control. We want to rate the product shown on the detail page, so we
create a composition of multiple standard controls using the SAPUI5 extension mechanism and add some glue code to make them work nicely together.
This way, we can reuse the control across the app and keep all related functionality in one module.
35. Step 35: Responsiveness
In this step, we improve the responsiveness of our app. SAPUI5 applications can be run on phone, tablet, and desktop devices and we can configure the
application to make best use of the screen estate for each scenario. Fortunately, SAPUI5 controls like the sap.m.Table already deliver a lot of
features that we can use.
36. Step 36: Device Adaptation
We now configure the visibility and properties of controls based on the device that we run the application on. By making use of the sap.ui.Device
API and defining a device model we will make the app look great on many devices.
37. Step 37: Content Density
In the last step of our Walkthrough tutorial, we adjust the content density based on the users device. SAPUI5 contains different content densities
allowing you to display larger controls for touch-enabled devices and a smaller, more compact design for devices that are operated by mouse. In our
app, we will detect the device and adjust the density accordingly.
38. Summary
You should now be familiar with the major development paradigms and concepts of SAPUI5 and have created a very simple first app. You are now ready
to build a proper app based on what you've learned.
1.3.2.1 Step 1: Hello World!

As you know SAPUI5 is all about HTML5. Lets get started with building a first Hello World with only HTML.
Preview
Figure 1: The browser shows the text "Hello World"
Coding
You can view and download all files in the Explored app in the Demo Kit under Walkthrough - Step 1 .
webapp/index.html (New)
<!DOCTYPE html >
<html>

<head>
<title>Walkthrough</title>
</head>
<body>
<p>Hello World</p>
</body>
</html>
Create a new folder webapp which will contain all sources of the app we will create throughout this tutorial. Therefore, we refer to this folder as app folder.
Now create a new root HTML file called index.html in your app folder. An HTML document consists basically of two sections: head and body. The head part
will be used by the browser to process the document. Using meta tags we can influence the behavior of the browser.
In this case we will tell Microsoft Internet Explorer to use the latest rendering engine (edge) and the document character set will be UTF-8. We will also give
our app a title that will be displayed in the browser. Be aware that our hard-coded title can be overruled by the app, for example to show a title in the language
of the user.
The body part describes the layout of the page. In our case we simply display Hello World by using a p tag.
Tip
Typically, the content of the webapp folder is deployed to a Web server as an application package. When deploying the webapp folder itself the URL for
accessing the index.html file contains webapp in the path.
Conventions
Name the root HTML file of the app index.html and locate it in the webapp folder.
Parent topic: Walkthrough
Next: Step 2: Bootstrap
1.3.2.2 Step 2: Bootstrap

Before we can do something with SAPUI5, we need to load and initialize it. This process of loading and initializing SAPUI5 is called bootstrapping. Once this
bootstrapping is finished, we simply display an alert.
Preview
Figure 1: An alert "UI5 is ready" is displayed
Coding
webapp/index.html
Note
SAPUI5 is a JavaScript library that can either be loaded from the same Web server where the app resides, or from a different server. The code examples
in this tutorial always show relative paths and assume that SAPUI5 is deployed locally in the resources folder of your Web server's root context.
If SAPUI5 is deployed somewhere else on the server or you want to use a different server, then you need to adjust the corresponding paths in the
bootstrap (here: src="/resources/sap-ui-core.js") in this tutorial according to your own requirements. SAPUI5 can also be retrieved from the
Content Delivery Network (CDN) at https://sapui5.hana.ondemand.com/resources/sap-ui-core.js .
You can use this reference to the latest stable version of SAPUI5 for the tutorial or for testing purposes, but never use this for productive use. In an actual
app, you always have to specify an SAPUI5 version explicitly.
For more information about the CDN, see Variant for Bootstrapping from Content Delivery Network.
In case you are using SAP Web IDE, you can right-click the project and select New Cloud Connectivity Configuration to make the /resources
reference work. This creates the neo-app.json file, which configures a URL mapping for this path.
<!DOCTYPE html>
<html>
<head>

<script
data-sap-ui-libs="sap.m"
</script>
<script>
alert("UI5 is ready");
});
</script>
</head>
<body>
<p>Hello World</p>
</body>
</html>
In this step, we load the SAPUI5 framework from our local webserver and initialize the core modules with the following configuration options:
The src attribute of the first <script> tag tells the browser where to find the SAPUI5 core library it initializes the SAPUI5 runtime and loads
additional resources, such as the libraries specified in the data-sap-ui-libs attribute.
The SAPUI5 controls support different themes, we choose sap_bluecrystal as our default theme.
We specify the required UI library sap.m containing the UI controls we need for this tutorial.
To make use of the most recent functionality of SAPUI5 we define the compatibility version as edge.
We configure the process of bootstrapping to run asynchronously.
This means that the SAPUI5 resources can be loaded simultaneously in the background for performance reasons.
When all resources and libraries are loaded, the SAPUI5 runtime fires the global init event to signal that the library is ready. It is a good practice to listen for
this event in order to trigger your application logic only after the event has been fired.
In the example above, we get a reference to the SAPUI5 core by calling sap.ui.getCore() and register an anonymous callback function for the init
event by calling attachInit() on the core. In SAPUI5 these kinds of callback functions are often referred to as handlers, listener functions, or simply
listeners. The core is a Singleton and can be accessed from anywhere in the code.
Our anonymous callback function is executed when the bootstrap of SAPUI5 is finished and displays a native JavaScript alert.
The sap-ui-core.js file contains a copy of jQuery, this means that you can use all jQuery features.
Previous: Step 1: Hello World!
Next: Step 3: Controls
Related Information
Bootstrapping: Loading and Initializing
Preload Variant for Bootstrapping
Compatibility Version Information
Variant for Bootstrapping from Content Delivery Network
https://jquery.org/
1.3.2.3 Step 3: Controls

Now it is time to build our first little UI by replacing the Hello World text in the HTML body by the SAPUI5 control sap.m.Text. In the beginning, we will use
the JavaScript control interface to set up the UI, the control instance is then placed into the HTML body.
Preview
Figure 1: The "Hello World" text is now displayed by a SAPUI5 control
Coding

webapp/index.html
<!DOCTYPE html>
<html>
<head>
<script
</script>
<script>
new sap.m.Text({
text : "Hello World"
});
</script>
</head>
</body>
</html>
Instead of using native JavaScript to display a dialog we want to use a simple SAPUI5 control. Controls are used to define appearance and behavior of parts
of the screen.
In the example above, the callback of the init event is where we now instantiate a SAPUI5 text control. The name of the control is prefixed by the
namespace of its control library sap.m and the options are passed to the constructor with a JavaScript object. For our control we set the text property to the
value Hello World.
We chain the constructor call of the control to the standard method placeAt that is used to place SAPUI5 controls inside a node of the document object
model (DOM) or any other SAPUI5 control instance. We pass the ID of a DOM node as an argument. As the target node we use the body tag of the HTML
document and give it the ID content. The class sapUiBody adds additional theme-dependent styles for displaying SAPUI5 apps.
All controls of SAPUI5 have a fixed set of properties, aggregations, and associations for configuration. You can find their descriptions in the Explored app in
the Demo Kit. In addition, each controls comes with a set of public functions that you can look up in the API reference.
Dont forget to remove the Hello World p.
Note
Only instances of sap.ui.core.Control or their subclasses can be rendered stand-alone and have a placeAt function. Each control extends
sap.ui.core.Element that can only be rendered inside controls. Check the API reference to learn more about the inheritance hierarchy of controls.
The API documentation of each control refers to the directly known subclasses.
Previous: Step 2: Bootstrap
Next: Step 4: XML Views
Related Information
Working with Controls
1.3.2.4 Step 4: XML Views

Putting all our UI into the index.html file will very soon result in a messy setup and there is quite a bit of work ahead of us. So lets do a first modularization
by putting the sap.m.Text control into a dedicated view. SAPUI5 supports multiple view types (XML, HTML, JavaScript). We choose XML as this produces
the most readable code and will force us to separate the view declaration from the controller logic. Yet the look of our UI will not change.
Preview

Figure 1: The "Hello World" text is now displayed by a SAPUI5 control (No visual changes to last step)
Coding
webapp/view/App.view.xml (New)
<mvc:View
xmlns="sap.m"
xmlns:mvc="sap.ui.core.mvc">
</mvc:View>
We create a new view folder in our app and a new file for our XML view inside the app folder. The root node of the XML structure is the view. Here, we
reference the default namespace sap.m where the majority of our UI assets is located. We define an additional sap.ui.core.mvc namespace with alias
mvc, where the SAPUI5 views and all other Model-View-Controller (MVC) assets are located.
webapp/view/App.view.xml
<mvc:View
xmlns="sap.m"
<Text text="Hello World"/>
</mvc:View>
Inside the view tag, we add the declarative definition of our text control with the same properties as in the previous step. The XML tags are mapped to
controls and the attributes are mapped to the properties of the control.
In SAPUI5, each control has its own ID. In the XML view above we did not specify an ID attribute, and therefore the SAPUI5 runtime generates an own ID and
adds it to the control. However, it is a good practice to set the IDs of controls explicitly, so that controls can be identified easily.
webapp/index.html
<!DOCTYPE html>
<html>
<head>
<script
data-sap-ui-preload="async"
data-sap-ui-resourceroots='{
"sap.ui.demo.wt": "./"
}' >
</script>
<script>
sap.ui.xmlview({
viewName : "sap.ui.demo.wt.view.App"
});
</script>
</head>
</body>
</html>
We tell SAPUI5 core that resources in the sap.ui.demo.wt namespace are located in the same folder as index.html. This is, for example, necessary for
apps that run in the SAP Fiori launchpad.
We replace the instantiation of the sap.m.Text control by our new App XML view. The view is created by a factory function of SAPUI5 which makes sure
that the view is correctly configured and can be extended by customers. The name is prefixed with the namespace sap.ui.demo.wt.view in order to
uniquely identify this resource.

Note
From this step onwards, it is necessary to run the app on a Web server. We structure the app with multiple files that are loaded from the local file system.
Without a Web server, this is prevented by the browser due to security reasons. If the error message "sap is not defined" appears in the developer tools of
the browser, you need to check the resource path in the bootstrap.
Conventions
View names are capitalized
All views are stored in the view folder
Names of XML views always end with *.view.xml
The default XML namespace is sap.m
Other XML namespaces use the last part of the SAP namespace as alias (for example, mvc for sap.ui.core.mvc
Previous: Step 3: Controls
Next: Step 5: Controllers
Related Information
Model View Controller (MVC)
Views
XML View
1.3.2.5 Step 5: Controllers

In this step, we replace the text with a button and show the Hello World message when the button is pressed. The handling of the button's press event is
implemented in the controller of the view.
Preview
Figure 1: A Say Hello button is added
Coding
<mvc:View
controllerName="sap.ui.demo.wt.controller.App"
xmlns="sap.m"
<Button
text="Say Hello"
press="onShowHello"/>
</mvc:View>
We add a reference to the controller, and replace the text control with a button with text Say Hello. The button triggers the onShowHello event handler
function when being pressed. We also have to specify the name of the controller that is connected to the view and holds the onShowHello function by
setting the controllerName attribute of the view.
A view does not necessarily need an explicitly assigned controller. You do not have to create a controller if the view is just displaying information and no
additional functionality is required. If a controller is specified, it is instantiated after the view is loaded.
webapp/controller/App.controller.js (New)
sap.ui.define([
"sap/ui/core/mvc/Controller"
], function (Controller) {
"use strict";
return Controller.extend("", {
});
});

We create the folder webapp/controller and a new file App.controller.js inside. For now, we ignore the code that manages the required modules.
We will explain this part in the next step.
Note
The "use strict"; literal expression was introduced by JavaScript 1.8.5 (ECMAScript 5). It tells the browser to execute the code in a so called strict
mode. The strict mode helps to detect potential coding issues at an early state at development time, that means, for example, it makes sure that
variables are declared before they are used. Thus, it helps to prevent common JavaScript pitfalls and its therefore a good practice to use strict mode.
webapp/controller/App.controller.js
sap.ui.define([
"use strict";
return Controller.extend("sap.ui.demo.wt.controller.App", {
onShowHello : function () {
// show a native JavaScript alert
alert("Hello World");
}
});
});
We define the app controller in its own file by extending the Controller object of the SAPUI5 core. In the beginning it holds only a single function called
onShowHello that handles the button's press event by showing an alert.
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
Controller names always end with *.controller.js
Previous: Step 4: XML Views
Next: Step 6: Modules
Related Information
Controller
1.3.2.6 Step 6: Modules

In SAPUI5, resources are often referred to as "modules". In this step, we replace the alert from the last exercise with a proper "Message Toast" from the
sap.m library. The required modules are enabled to be loaded asynchronously.
Preview
Figure 1: A message toast displays the "Hello World" message
Coding
sap.ui.define([
"sap/ui/core/mvc/Controller",
"sap/m/MessageToast"

], function (Controller, MessageToast) {
"use strict";
MessageToast.show("Hello World");
}
});
});
We extend the array of required modules with the fully qualified path to sap.m.MessageToast. Once both modules, Controller and MessageToast, are
loaded, the callback function is called and we can make use of both objects by accessing the parameters passed on to the function.
This Asynchronous Module Definition (AMD) syntax allows to clearly separate the module loading from the code execution and greatly improves the
performance of the application. The browser can decide when and how the resources are loaded prior to code execution.
Conventions
Use sap.ui.define for controllers and all other JavaScript modules to define a global namespace. With the namespace, the object can be addressed
throughout the application.
Use sap.ui.require for asynchronously loading dependencies but without declaring a namespace, for example code that just needs to be executed,
but does not need to be called from other code.
Use the name of the artifact to load for naming the function parameters (without namespace).
Previous: Step 5: Controllers
Next: Step 7: JSON Model
1.3.2.7 Step 7: JSON Model

Now that we have set up the view and controller, its about time to think about the "M" in MVC. We will add an input field to our app, bind its value to the
model, and bind the same value to the description of the input field. The description will be directly updated as the user types.
Preview
Figure 1: An input field and a description displaying the value of the input field
Coding
sap.ui.define([
"sap/m/MessageToast",
"sap/ui/model/json/JSONModel"
], function (Controller, MessageToast, JSONModel) {
"use strict";
onInit : function () {
// set data model on view
var oData = {
recipient : {
name : "World"
}
};
var oModel = new JSONModel(oData);
this.getView().setModel(oModel);
},
MessageToast.show("Hello World");
}
});
});
We add an init function to the controller. onInit is one of SAPUI5s lifecycle methods that is invoked by the framework when the controller is created, similar
to a constructor function of a control.
Inside the function we instantiate a JSON model. The data for the model only contains a single property for the recipient, and inside this it also contains one
additional property for the name.
To be able to use this model from within the XML view, we call the setModel function on the view and pass on our newly created model. The model is now
set on the view.

The message toast is just showing the static "Hello World" message. We will show how to load a translated text here in the next step.
<mvc:View
xmlns="sap.m"
<Button
text="Say Hello"
<Input
value="{/recipient/name}"
description="Hello {/recipient/name}"
valueLiveUpdate="true"
width="60%"/>
</mvc:View>
We add an sap.m.Input control to the view. With this, the user can enter a recipient for the greetings. We bind its value to a SAPUI5 model by using the
declarative binding syntax for XML views:
The curly brackets {} indicate that data is taken from the value of the recipient's object name property. This is called "data binding".
/recipient/name declares the path in the model.
webapp/index.html
<!DOCTYPE html>
<html>
<head>
<script
}' >
</script>
<script>
sap.ui.xmlview({
viewName: "sap.ui.demo.wt.view.App"
});
</script>
</head>
</body>
</html>
The binding of the value attribute is a simple binding example that contains only a binding pattern. We can also combine texts and binding pattern to a more
complex binding result as seen in the description attribute. To be able to use the so-called complex binding syntax we have to enable it globally by setting the
bootstrap parameter data-sap-ui-compatVersion to edge. If this setting is omitted, then only standard binding syntax is allowed, meaning "Hello
{/recipient/name}" would not work anymore while "{/recipient/name}" would work just fine.
Note
You can either use data-sap-ui-compatVersion="edge" or data-sap-ui-bindingSyntax="complex" in the script. By setting the edge
compatibility mode, the complex binding syntax is automatically enabled. The edge mode automatically enables compatibility features that otherwise
would have to be enabled manually. For more information, see Compatibility Version Information.
Conventions
Use Hungarian notation for variable names.
Previous: Step 6: Modules
Next: Step 8: Translatable Texts
Related Information

Data Binding
Declarative Support
JSON Model
1.3.2.8 Step 8: Translatable Texts

In this step we move the texts of our UI to a separate resource file. This way, they are all in a central place and can be easily translated into other languages.
This process of internationalization in short i18n is achieved in SAPUI5 by using a special resource model and the standard data binding syntax, but
without preceding /.
Preview
Figure 1: An input field and a description displaying the value of the input field (No visual changes to last step)
Coding
webapp/i18n/i18n.properties (New)
showHelloButtonText=Say Hello
helloMsg=Hello {0}
We create the folder webapp/i18n and the file i18n.properties inside. The resolved bundle name is sap.ui.demo.wt.i18n, as we will see later. The
properties file for texts contains name-value pairs for each element. You can add any number of parameters to the texts by adding numbers in curly
brackets to them. These numbers correspond to the sequence in which the parameters are accessed (starting with 0).
In this tutorial we will only have one properties file. However, in real-world projects, you would have a separate file for each supported language with a suffix for
the locale, for example i18n_de.properties for German, i18n_en.properties for English, and so on. When a user runs the app, SAPUI5 will load the
language file that fits best to the user's environment.
controller/App.controller.js
sap.ui.define([
"sap/ui/model/json/JSONModel",
"sap/ui/model/resource/ResourceModel"
], function (Controller, MessageToast, JSONModel, ResourceModel) {
"use strict";
// set data model on view
var oData = {
recipient : {
name : "World"
}
};
this.getView().setModel(oModel);
// set i18n model on view
var i18nModel = new ResourceModel({
bundleName: "sap.ui.demo.wt.i18n.i18n"
});
this.getView().setModel(i18nModel, "i18n");
},
// read msg from i18n model
var oBundle = this.getView().getModel("i18n").getResourceBundle();
var sRecipient = this.getView().getModel().getProperty("/recipient/name");
var sMsg = oBundle.getText("helloMsg", [sRecipient]);
// show message
MessageToast.show(sMsg);
}
});
});
In the onInit function we instantiate the ResourceModel that points to the new message bundle file where our texts are now located (i18n.properties
file). The bundle name sap.ui.demo.wt.i18n.i18n consists of the application namespace sap.ui.demo.wt (the application root as defined in the
index.html), the folder name i18n and finally the file name i18n without extension. The SAPUI5 runtime calculates the correct path to the resource; in
this case the path to our i18n.properties file. Next, the model instance is set on the view as a named model with the key i18n. You use named models
when you need to have several models available in parallel.
In the onShowHello event handler function we access the i18n model to get the text from the message bundle file and replace the placeholder {0} with the

recipient from our data model. The getProperty method can be called in any model and takes the data path as an argument. In addition, the resource
bundle has a specific getText method that takes an array of strings as second argument.
The resource bundle can be accessed with the getResourceBundle method of a ResourceModel. Rather than concatenating translatable texts manually,
we can use the second parameter of getText to replace parts of the text with non-static data. During runtime, SAPUI5 tries to load the correct
i18n_*.properties file based on your browser settings and your locale. In our case we have only created one i18n.properties file to make it simple.
However, you can see in the network traffic of your browsers developer tools that SAPUI5 tries to load one or more i18n_*.properties files before falling
back to the default i18n.properties file.
<mvc:View
xmlns="sap.m"
<Button
text="{i18n>showHelloButtonText}"
<Input
width="60%"/>
</mvc:View>
In the XML view, we use data binding to connect the button text to the sayHelloButtonText property in the i18n model. A resource bundle is a flat
structure, therefore the preceding slash (/) can be omitted for the path.
Note
The description text is not completely localized in this example for illustration purposes. To be on the safe side, we would have to use a similar
mechanism as in the controller to use a string from the resource bundle and replace parts of it. This can be done with the jQuery.sap.formatMessage
formatter.
Furthermore, i18n files only impact client-side application texts. Texts that are loaded from back-end systems can appear in all languages that are
supported by the back-end system.
Conventions
The resource model for internationalization is called the i18n model.
The default filename is i18n.properties.
Resource bundle keys are written in (lower) camelCase.
Resource bundle values can contain parameters like {0}, {1}, {2},
Never concatenate strings that are translated, always use placeholders.
Use Unicode escape sequences for special characters.
Previous: Step 7: JSON Model
Next: Step 9: Component Configuration
Related Information
Resource Model
1.3.2.9 Step 9: Component Configuration

After we have introduced all three parts of the Model-View-Controller (MVC) concept, we now come to another important structural aspect of SAPUI5. In this
step, we will encapsulate all UI assets in a component that is independent from our index.html file. Components are independent and reusable parts used in
SAPUI5 applications. Whenever we access resources, we will now do this relatively to the component (instead of relatively to the index.html). This
architectural change allows our app to be used in more flexible environments than our static index.html page, such as in a surrounding container like the
SAP Fiori launchpad.
Preview
Coding

Figure 2: Folder Structure for this Step
After this step your project structure will look like the figure above. We will create the Component.js file now and modify the related files in the app.
webapp/Component.js (New)
sap.ui.define([
"sap/ui/core/UIComponent"
], function (UIComponent) {
"use strict";
return UIComponent.extend("", {
init : function () {
// call the init function of the parent
UIComponent.prototype.init.apply(this, arguments);
}
});
});
We create an initial Component.js file in the webapp folder that will hold our application setup. The init function of the component is automatically invoked
by SAPUI5 when the component is instantiated. Our component inherits from the base class sap.ui.core.UIComponent and it is obligatory to make the
super call to the init function of the base class in the overridden init method.
webapp/Component.js
sap.ui.define([
"sap/ui/core/UIComponent",
"sap/ui/model/resource/ResourceModel"
], function (UIComponent, JSONModel, ResourceModel) {
"use strict";
return UIComponent.extend("sap.ui.demo.wt.Component", {
metadata : {
rootView: "sap.ui.demo.wt.view.App"
},
// set data model
var oData = {
recipient : {
name : "World"
}
};
this.setModel(oModel);
// set i18n model

var i18nModel = new ResourceModel({
bundleName : "sap.ui.demo.wt.i18n.i18n"
});
this.setModel(i18nModel, "i18n");
}
});
});
The Component.js file consists of two parts now: The new metadata section that simply defines a reference to the root view and the previously introduced
init function that is called when the component is initialized. Instead of displaying the root view directly in the index.html file as we did previously, the
component will now manage the display of the app view.
In the init function we instantiate our data model and the i18n model like we did before in the app controller. Be aware that the models are directly set on
the component and not on the root view of the component. However, as nested controls automatically inherit the models from their parent controls, the models
will be available on the view as well.

sap.ui.define([
"use strict";
// show message
}
});
});
Delete the onIinit function and the required modules; this is now done in the component. You now have the code shown above.
webapp/index.html
<!DOCTYPE html>
<html>
<head>
<script
data-sap-ui-bindingSyntax="complex"
}' >
</script>
<script>
new sap.ui.core.ComponentContainer({
name : "sap.ui.demo.wt"
});
</script>
</head>
</body>
</html>
On the index page we now instantiate the component instead of the app view. The helper method sap.ui.core.ComponentContainer instantiates the
component by searching for a Component.js file in the namespace that is passed in as an argument. The component automatically loads the root view that
we have defined above and displays it. If you now call the index.html file, the app should still look the same, but is now packaged into a UI component.
Conventions
The component is named Component.js.
Together with all UI assets of the app, the component is located in the webapp folder.
The index.html file is located in the webapp folder if it is used productively.
Previous: Step 8: Translatable Texts
Next: Step 10: Descriptor for Applications
Related Information
Components
1.3.2.10 Step 10: Descriptor for Applications

All application-specific configuration settings will now further be put in a separate descriptor file called manifest.json. This clearly separates the application
coding from the configuration settings and makes our app even more flexible. For example, all SAP Fiori applications are realized as components and come
with a descriptor file in order to be hosted in the SAP Fiori launchpad.

The SAP Fiori launchpad acts as an application container and instantiates the app without having a local HTML file for the bootstrap. Instead, the descriptor
file will be parsed and the component is loaded into the current HTML page. This allows several apps to be displayed in the same context. Each app can
define local settings, such as language properties, supported devices, and more. And we can also use the descriptor file to load additional resources and
instantiate models like our i18n resource bundle.
Preview
Coding
Caution
Automatic model instantiation is only available as of SAPUI5 version 1.30. If you are using an older version, you can manually instantiate the resource
bundle and other models of the app in the init method of the Component.js file as we did in Step 9: Component Configuration.
webapp/manifest.json (New)
{
"_version": "1.1.0",
"sap.app": {
"_version": "1.1.0",
"id": "sap.ui.demo.wt",
"type": "application",
"i18n": "i18n/i18n.properties",
"title": "{{appTitle}}",
"description": "{{appDescription}}",
"applicationVersion": {
"version": "1.0.0"
}
},
"sap.ui": {
"_version": "1.1.0",
"technology": "UI5",
"deviceTypes": {
"desktop": true,
"tablet": true,
"phone": true
},
"supportedThemes": [
"sap_bluecrystal"
]
},
"sap.ui5": {
"_version": "1.1.0",
"rootView": "sap.ui.demo.wt.view.App",
"dependencies": {
"minUI5Version": "1.30",
"libs": {
"sap.m": {}
}
},
"models": {
"i18n": {
"type": "sap.ui.model.resource.ResourceModel",
"settings": {
"bundleName": "sap.ui.demo.wt.i18n.i18n"
}
}
}
}
}
The content of the manifest.json file is a configuration object in JSON format that contains all global application settings and parameters. The manifest file
is called the descriptor for applications, components, and libraries and is also referred to as descriptor or app descriptor when used for applications. It is
stored in the webapp folder and read by SAPUI5 to instantiate the component. There are three important sections defined by namespaces in the
manifest.json file:
sap.app
The sap.app namespace contains the following application-specific attributes:
id (mandatory): The namespace of our application component
The ID must not exceed 70 characters. It must be unique and must correspond to the component ID/namespace.
type: Defines what we want to configure, here: an application

i18n: Defines the path to the resource bundle file
title: Title of the application in handlebars syntax referenced from the app's resource bundle
description: Short description text what the application does in handlebars syntax referenced from the app's resource bundle
applicationVersion: The version of the application to be able to easily update the application later on
sap.ui
The sap.ui namespace contributes the following UI-specific attributes:
technology: This value specifies the UI technology; in our case we use SAPUI5
deviceTypes: Tells what devices are supported by the app: desktop, tablet, phone (all true by default)
supportedThemes: An array containing a list of SAP themes supported by the app, for example sap_bluecrystal
sap.ui5
The sap.ui5 namespace adds SAPUI5-specific configuration parameters that are automatically processed by SAPUI5. The most important parameters
are:
rootView: If you specify this parameter, the component will automatically instantiate the view and use it as the root for this component
dependencies: Here we declare the UI libraries used in the application
models: In this section of the descriptor we can define models that will be automatically instantiated by SAPUI5 when the app starts. Here we
can now define the local resource bundle. We define the name of the model "i18n" as key and specify the bundle file by namespace. As in the
previous steps, the file with our translated texts is stored in the i18n folder and named i18n.properties. We simply prefix the path to the file
with the namespace of our app. The manual instantiation in the app component's init method will be removed later in this step.
For compatibility reasons the root object and each of the sections state the descriptor version number 1.1.0 under the internal property _version.
Features might be added or changed in future versions of the descriptor and the version number helps to identify the application settings by tools that
read the descriptor.
Note
Properties of the resource bundle are enclosed in two curly brackets in the descriptor. This is not a SAPUI5 data binding syntax, but a variable reference to
the resource bundle in the descriptor in handlebars syntax. The referred texts are not visible in the app built in this tutorial but can be read by an application
container like the SAP Fiori launchpad.
webapp/i18n/i18n.properties
# App Descriptor
appTitle=Hello World
appDescription=A simple walkthrough app that explains the most important concepts of SAPUI5
# Hello Panel
helloMsg=Hello {0}
In the resource bundle we simply add the texts for the app and add comments to separate the bundle texts semantically.
webapp/Component.js
sap.ui.define([
], function (UIComponent, JSONModel) {
"use strict";
metadata : {
manifest: "json"
},
// set data model
var oData = {
recipient : {
name : "World"
}
};
}
});
});
In the component's metadata section, we now replace the rootView property with the property key manifest and the value json. This defines a
reference to the descriptor that will be loaded and parsed automatically when the component is instantiated. We can now completely remove the lines of code
containing the model instantiation for our resource bundle. It is done automatically by SAPUI5 with the help of the configuration entries in the descriptor. We
can also remove the dependency to sap/ui/model/resource/ResourceModel and the corresponding formal parameter ResourceModel because we
will not use this inside our anonymous callback function.
Tip
In previous versions of SAPUI5, additional configuration settings for the app, like the service configuration, the root view, and the routing configuration, had
to be added to the metadata section of the Component.js file. As of SAPUI5 version 1.30, we recommend that you define these settings in the
manifest.json descriptor file. Apps and examples that were created based on an older SAPUI5 version still use the Component.js file for this
purpose - so it is still supported, but not recommended.

Conventions
The descriptor file is named manifest.json and located in the webapp folder.
Use translatable strings for the title and the description of the app.
Previous: Step 9: Component Configuration
Next: Step 11: Pages and Panels
Related Information
1.3.2.11 Step 11: Pages and Panels

After all the work on the app structure its time to improve the look of our app. We will use two controls from the sap.m library to add a bit more "bling" to our
UI. You will also learn about control aggregations in this step.
Preview
Figure 1: A panel is now displaying the controls from the previous steps
Coding
<mvc:View
xmlns="sap.m"
xmlns:mvc="sap.ui.core.mvc"
displayBlock="true">
<App>
<pages>
<Page title="{i18n>homePageTitle}">
<content>
<Panel
headerText="{i18n>helloPanelTitle}">
<content>
<Button
<Input
width="60%"/>
</content>
</Panel>
</content>
</Page>
</pages>
</App>
</mvc:View>
We put both the input field and the button inside a containing control called sap.m.Page. The page provides an aggregation to 0..N other controls called
content. It also displays the title attribute in a header section on top of the content. The page itself is placed into the pages aggregation of another control
called sap.m.App which does the following important things for us:
It writes a bunch of properties into the header of the index.html that are necessary for proper display on mobile devices.
It offers functionality to navigate between pages with animations. We will use this soon.

In order to make the fullscreen height of the view work properly, we add the displayBlock attribute with the value true to the view. The actual content is
wrapped inside a Panel control, in order to group related content.
# App Descriptor
# Hello Panel
helloMsg=Hello {0}
homePageTitle=Walkthrough
helloPanelTitle=Hello World
We add new key/value pairs to our text bundle for the start page title and the panel title.
Conventions
Do not make implicit use of default aggregations but always declare the aggregation names explicitly in the view. In the example above, the content
aggregation could also be omitted as the Panel control declares it as a default, but it makes the view harder to read.
Previous: Step 10: Descriptor for Applications
Next: Step 12: Shell Control as Container
1.3.2.12 Step 12: Shell Control as Container

Now we use a shell control as container for our app and use it as our new root element. The shell takes care of visual adaptation of the application to the
devices screen size by introducing a so-called letterbox on desktop screens.
Preview
Figure 1: The app is now run in a shell that limits the app width
Coding
webapp/index.html
<!DOCTYPE html>
<html>
<head>

<script>
new sap.m.Shell({
app : new sap.ui.core.ComponentContainer({
name : "sap.ui.demo.wt",
height : "100%"
})
});

</script>
</head>
</body>
</html>
The shell control is now the outermost control of our app and automatically displays a so-called letterbox, if the screen size is larger than a certain width, all
we need to do is to assign our component to the aggregation app of the shell.
Note
We do not add the Shell control to the declarative UI definition in the XML view, because apps that run in an external shell, like the SAP Fiori launchpad,
there will already be a shell around the component UI.
There are further options to customize the shell, like setting a custom background image or color and setting a custom logo. Check the related API reference
for more details.
Previous: Step 11: Pages and Panels
Next: Step 13: Margins and Paddings
1.3.2.13 Step 13: Margins and Paddings

Our app content is still glued to the corners of the letterbox. To fine-tune our layout, we can add margins and paddings to the controls that we added in the
previous step. But instead of manually adding CSS to the controls, we will use the standard classes provided by SAPUI5. These classes take care of
consistent sizing steps, left-to-right support, and responsiveness.
Preview
Figure 1: The layout of the panel and its content now has margins and padding
Coding
<mvc:View
xmlns="sap.m"
<App>
<pages>
<content>
<Panel
headerText="{i18n>helloPanelTitle}"
class="sapUiResponsiveMargin"
width="auto">
<content>
<Button
press="onShowHello"
class="sapUiSmallMarginEnd"/>
<Input
width="60%"/>
<Text
text="Hello {/recipient/name}"
class="sapUiSmallMargin"/>

</content>
</Panel>
</content>
</Page>
</pages>
</App>
</mvc:View>
To layout the panel, we add the CSS class sapUiResponsiveMargin that will add some space around the panel. We have to set the width of the panel to
auto since the margin would otherwise be added to the default width of 100% and exceed the page size.
If you decrease the screen size, then you can actually see that the margin also decreases. As the name suggests, the margin is responsive and adapts to the
screen size of the device. Tablets will get a smaller margin and phones in portrait mode will not get a margin to save space on these small screens.
Margins can be added to all kinds of controls and are available in many different options. We can even add space between the button and the input field by
adding class sapUiSmallMarginEnd to the button.
To format the output text individually, we remove the description from the input field and add a new Text control with the same value. Here we also use a
small margin to align it with the other content. Similarly, we could add the standard padding classes to layout the inner parts of container controls such as our
panel, but as it already brings a padding by default, this is not needed here.
Conventions
Use the standard SAPUI5 CSS classes for the layout if possible.
Previous: Step 12: Shell Control as Container
Next: Step 14: Custom CSS and Theme Colors
Related Information
Using Predefined CSS Margin Classes
Using Container Content Padding CSS Classes
1.3.2.14 Step 14: Custom CSS and Theme Colors

Sometimes we need to define some more fine-granular layouts and this is when we can use the flexibility of CSS by adding custom style classes to controls
and style them as we like.
Preview
Figure 1: The space between the button and the input field is now smaller and the output text is blue
Caution
As stated in the Compatibility Rules, the HTML and CSS generated by SAPUI5 is not part of the public API and may change in patch and minor releases.
If you decide to override styles, you have the obligation to test and update your modifications each time SAPUI5 is updated. A prerequisite for this is that
you have control over the version of SAPUI5 being used, for example in a standalone scenario. This is not possible when running your app in the SAP Fiori
launchpad where SAPUI5 is centrally loaded for all apps. As such, SAP Fiori launchpad apps should not override styles.
Coding
webapp/css/style.css (New)
.myAppDemoWT .myCustomButton.sapMBtn {
margin-right: 0.125rem
}

html[dir="rtl"] .myAppDemoWT .myCustomButton.sapMBtn {
margin-left: 0.125rem;
margin-right: 0
}
.myAppDemoWT .myCustomText {
font-weight: bold;
}
We create a folder css which will contain our CSS files. In a new style definition file inside the css folder we create our custom classes combined with a
custom namespace class. This makes sure that the styles will only be applied on controls that are used within our app.
A button has a default margin of 0 that we want to override: We add a custom margin of 2px (or 0.125rem calculated relatively to the default font size of
16px) to the button with the style class myCustomButton. We add the CSS class sapMBtn to make our selector more specific: in CSS, the rule with the
most specific selector "wins".
For right-to-left (rtl) languages, like Arabic, you set the left margin and reset the right margin as the app display is inverted. If you only use standard SAPUI5
controls, you don't need to care about this, in this case where we use custom CSS, you have to add this information.
In an additional class myCustomText we define a bold text. This time we just define our custom class without any additional selectors.
webapp/manifest.json
...
"sap.ui5": {
...
"models": {
...
},
"resources": {
"css": [
{
"uri": "css/style.css"
}
]
}
}
In the resources section of the sap.ui5 namespace, additional resources for the app can be loaded. We load the CSS styles by defining a URI relative to
the component. SAPUI5 then adds this file to the header of the HTML page as a <link> tag, just like in plain Web pages, and the browser loads it
automatically.
<mvc:View
xmlns="sap.m"
<App class="myAppDemoWT">
<pages>
<content>
<Panel
width="auto">
<content>
<Button
press="onShowHello"
class="myCustomButton"/>
<Input
width="60%"/>
<Text
class ="sapUiSmallMargin sapThemeHighlight-asColor myCustomText"/>
</content>
</Panel>
</content>
</Page>
</pages>
</App>
</mvc:View>
The app control is configured with our custom namespace class myAppDemoWT. This class has no styling rules set and is used in the definition of the CSS
rules to define CSS selectors that are only valid for this app.
We add our custom CSS class to the button to precisely define the space between the button and the input field. Now we have a pixel-perfect design for the

panel content.
To highlight the output text we add a theme-dependent CSS class that will put blue color on the text. For other themes, the color might be different, but we will
always have a semantic color set on the text. If we would have done this with custom CSS, the color might not fit to the current theme and the text could even
be unreadable. For a complete list of the available CSS class names, see CSS Classes for Theme Parameters.
Finally, we add myCustomText to the text control to make the text bold because the text control does not provide such an API property.
Conventions
Do not specify colors in custom CSS but use the standard theme-dependent classes instead.
Previous: Step 13: Margins and Paddings
Next: Step 15: Nested Views
Related Information
CSS Classes for Theme Parameters
Creating Themable User Interfaces
Compatibility Rules
1.3.2.15 Step 15: Nested Views

Our panel content is getting more and more complex and now it is time to move the panel content to a separate view. With that approach, the application
structure is much easier to understand, and the individual parts of the app can be reused.
Preview
Figure 1: The panel content is now refactored to a separate view (No visual changes to last step)
Coding
<mvc:View
xmlns="sap.m"
displayBlock="true" >
<App class="sapUiDemoWT">
<pages>
<content>
<mvc:XMLView viewName="sap.ui.demo.wt.view.HelloPanel"/>
</content>
</Page>
</pages>
</App>
</mvc:View>
Instead of putting the panel and its content directly into our App view, we will move it to a new separate HelloPanel view. We refer to this using an
XMLView tag in the content aggregation of the panel.
webapp/view/HelloPanel.view.xml (New)
<mvc:View

controllerName="sap.ui.demo.wt.controller.HelloPanel"
xmlns="sap.m"
<Panel
width="auto" >
<content>
<Button
press="onShowHello"
class="myAppDemoWT myCustomButton"/>
<Input
width="60%"/>
<Text
class="sapUiSmallMargin sapThemeHighlight-asColor myCustomText"/>
</content>
</Panel>
</mvc:View>
The whole content for the panel is now added to the new file HelloPanel.view.xml. We also specify the controller for the view by setting the
controllerName attribute of the XML view.
webapp/controller/HelloPanel.controller.js (New)
sap.ui.define([
"use strict";
return Controller.extend("sap.ui.demo.wt.controller.HelloPanel", {
// show message
}
});
});
To have a reusable asset, the method onShowHello is also moved from the app controller to the HelloPanel controller.
sap.ui.define([
"use strict";
});
});
We have now moved everything out of the app view and controller. The app controller remains an empty stub for now, we will use it later to add more
functionality.
Previous: Step 14: Custom CSS and Theme Colors
Next: Step 16: Dialogs and Fragments
1.3.2.16 Step 16: Dialogs and Fragments

In this step, we will take a closer look at another element which can be used to assemble views: the fragment.
Fragments are light-weight UI parts (UI subtrees) which can be reused but do not have any controller. This means, whenever you want to define a certain part
of your UI to be reusable across multiple views, or when you want to exchange some parts of a view against one another under certain circumstances
(different user roles, edit mode vs read-only mode), a fragment is a good candidate, especially where no additional controller logic is required.
A fragment can consist of 1 to n controls. At runtime, fragments placed in a view behave similar to "normal" view content, which means controls inside the
fragment will just be included into the views DOM when rendered. There are of course controls that are not designed to become part of a view, for example,
dialogs.
But even for these controls, fragments can be particularly useful, as you will see in a minute.
We will now add a dialog to our app. Dialogs are special, because they open on top of the regular app content and thus do not belong to a specific view. That
means the dialog must be instantiated somewhere in the controller code, but since we want to stick with the declarative approach and create reusable artifacts

to be as flexible as possible, and because dialogs cannot be specified as views, we will create an XML fragment containing the dialog. A dialog, after all, can
be used in more than only one view of your app.
Preview
Figure 1: A dialog opens when the new Say Hello With Dialog button is clicked
Coding
webapp/view/HelloPanel.view.xml
<mvc:View
xmlns="sap.m"
<Panel
width="auto" >
<content>
<Button
text="{i18n>openDialogButtonText}"
press="onOpenDialog"
<Button
press="onShowHello"
class="sapUiDemoWTmyCustomButton"/>
<Input
width="60%"/>
<Text
class="sapUiSmallMargin sapThemeHighlight-asColor sapUiDemoWTmyCustomText"/>
</content>
</Panel>
</mvc:View>
We add a new button to the view to open the dialog. It simply calls an event handler function in the controller of the panels content view.
webapp/view/HelloDialog.fragment.xml (New)
<core:FragmentDefinition
xmlns="sap.m"
xmlns:core="sap.ui.core" >
<Dialog
title="Hello {/recipient/name}">
</Dialog>
</core:FragmentDefinition>
We add a new XML file to declaratively define our dialog in a fragment. The fragment assets are located in the core namespace, so we add an xml
namespace for it inside the FragmentDefinition tag.
The syntax is similar to a view, but since fragments do not have a controller this attribute is missing. Also, the fragment does not have any footprint in the
DOM tree of the app, and there is no control instance of the fragment itself (only the contained controls). It is simply a container for a set of reuse controls.

webapp/controller/HelloPanel.controller.js
sap.ui.define([
"use strict";

},
_getDialog : function () {
if (!this._oDialog) {
this._oDialog = sap.ui.xmlfragment("sap.ui.demo.wt.view.HelloDialog");
this.getView().addDependent(this._oDialog);
}
return this._oDialog;
},
onOpenDialog : function () {
this._getDialog().open();
}
});
});
The internal _getDialog helper function is instantiating the fragment by calling the sap.ui.xmlfragment method with the path to the fragment definition
as an argument. The function returns the instantiated controls for further use in the app. In our case this is the dialog that we would like to open.
We store the reference to the dialog in a private property on the controller to be able to open the same instance again when another user action is triggered
(lazy instantiation with a singleton), and we add the fragment as "dependent" on the view to be connected to the views model lifecycle. A convenient side-
effect is that the dialog will automatically be destroyed when the view is destroyed. Otherwise, we would have to destroy the dialog manually to free its
resources.
# App Descriptor
# Hello Panel
helloMsg=Hello {0}
openDialogButtonText=Say Hello With Dialog
dialogCloseButtonText=Ok
The text bundle is extended by two new texts for the open button and the dialogs close button.
Conventions
Always use the addDependent method to connect the dialog to the lifecycle management and data binding of the view, even though it is not added to
its UI tree.
Private functions and variables should always start with an underscore.
Previous: Step 15: Nested Views
Next: Step 17: Fragment Callbacks
Related Information
Reusing UI Parts: Fragments
Dialogs and other Popups as Fragments
1.3.2.17 Step 17: Fragment Callbacks

Now that we have integrated the dialog, it's time to add some user interaction. The user will definitely want to close the dialog again at some point, so we add a
button to close the dialog and assign an event handler.
Preview

Figure 1: The dialog now has an "OK" button
Coding
sap.ui.define([
"use strict";

},
// create dialog lazily
// create dialog via fragment factory
this._oDialog = sap.ui.xmlfragment("sap.ui.demo.wt.view.HelloDialog", this);
// connect dialog to view (models, lifecycle)
this.getView().addDependent(this._oDialog);
}
},
this._getDialog().open();
},
onCloseDialog : function () {
this._getDialog().close();
}
});
});
As previously described, fragments are pure UI reuse artifacts and do not have a controller. The second parameter of the sap.ui.xmlfragment function is
optional and allows passing in a reference to a (controller) object. For our dialog we reference the HelloPanel controller. However, the second parameter
does not necessarily have to be a controller but can be any object.
The event handler function is put into the same controller file and it closes the dialog by accessing the internal helper function that returns the dialog.
webapp/view/HelloDialog.fragment.xml
xmlns="sap.m"
<Dialog
title ="Hello {/recipient/name}">
<beginButton>
<Button
text="{i18n>dialogCloseButtonText}"
press="onCloseDialog"/>
</beginButton>
</Dialog>
In the fragment definition, we add a button to the beginButton aggregation of the dialog. The press handler is referring to an event handler called
onCloseDialog, and since we passed in the reference to the HelloPanel controller, the method will be invoked there when the button is pressed. The
dialog has an aggregation named beginButton as well as endButton. Placing buttons in both of these aggregations makes sure that the beginButton is

placed before the endButton on the UI. What before means, however, depends on the text direction of the current language. We therefore use the terms
begin and end as a synonym to left and right". In languages with left-to-right direction, the beginButton will be rendered left, the endButton on the right
side of the dialog footer; in right-to-left mode for specific languages the order is switched.
Previous: Step 16: Dialogs and Fragments
Next: Step 18: Icons
Related Information
Reusing UI Parts: Fragments
Instantiation of Fragments
1.3.2.18 Step 18: Icons

Our dialog is still pretty much empty. Since SAPUI5 is shipped with a large icon font that contains more than 500 icons, we will add an icon to greet our users
when the dialog is opened.
Preview
Figure 1: An icon is now displayed in the dialog box
Coding
<mvc:View
xmlns="sap.m"
<Panel
width="auto" >
<content>
<Button
icon="sap-icon://world"
<Button
press="onShowHello"
class="sapUiDemoWTmyCustomButton"/>
<Input
width="60%"/>
<Text

</content>
</Panel>
</mvc:View>
We add an icon to the button that opens the dialog. The sap-icon:// protocol is indicating that an icon from the icon font should be loaded. The identifier
world is the readable name of the icon in the icon font.
Tip
You can look up other icons using the Icon Explorer in the Demo Kit.
The call any icon, use its name as listed in the Icon Explorer in sap-icon://<iconname>.
webapp/view/HelloDialog.fragment.xml
xmlns="sap.m"
<Dialog
title ="Hello {/recipient/name}">
<content>
<core:Icon
src="sap-icon://hello-world"
size="8rem"
class="sapUiMediumMargin"/>
</content>
<beginButton>
<Button
text="{i18n>dialogCloseButtonText}"
press="onCloseDialog"/>
</beginButton>
</Dialog>
In the dialog fragment, we add an icon control to the content aggregation of the dialog. Luckily, the icon font also comes with a Hello World icon that is
perfect for us here. We also define the size of the icon and set a medium margin on it.
Conventions
Always use icon fonts rather than images wherever possible, as they are scalable without quality loss (vector graphics) and do not need to be loaded
separately.
Previous: Step 17: Fragment Callbacks
Next: Step 19: Reuse Dialogs
1.3.2.19 Step 19: Reuse Dialogs

In step 16 we created a dialog as fragment, because we wanted it to be reusable across views or across our whole app. But we placed the logic for retrieving
the dialog instance and for opening and closing it respectively in the controller of the HelloPanel view. Sticking to this approach would require copying and
pasting the code to the controller of each view that needs our dialog. This would of course cause an undesired code redundancy we definitely want to avoid. In
this step, we will implement the solution to this problem: We now expand our reuse concept and invoke the dialog at component level.
Preview

Figure 1: The dialog is now opened by the component (no visual changes to last step)
Coding
webapp/Component.js
sap.ui.define([
"sap/ui/demo/wt/controller/HelloDialog"
], function (UIComponent, JSONModel, HelloDialog) {
"use strict";
metadata : {
manifest : "json"
},
// set data model
var oData = {
recipient : {
name : "World"
}
};
// set dialog
this.helloDialog = new HelloDialog();
}
});
});
The dialog instantiation is refactored to a new helper object that we can directly access through the component. In its initialization method we store a public
reference to it that can be accessed from every controller.
webapp/controller/HelloDialog.js (New)
sap.ui.define([
"sap/ui/base/Object"
], function (Object) {
"use strict";
return Object.extend("sap.ui.demo.wt.controller.HelloDialog", {
}
},
open : function (oView) {
var oDialog = this._getDialog();
oView.addDependent(oDialog);

// open dialog
oDialog.open();
},
onCloseDialog : function () {
}
});
});
The implementation of the HelloDialog reuse object extends a base object to inherit the core functionality of SAPUI5.
Our _getDialog method is refactored from the HelloPanel controller and instantiates our dialog fragment as in the previous steps. Note that now the
reuse object is passed on as a controller to the fragment.
The open method now contains our dialog instantiation. The first time the open method is called, the dialog is instantiated. The oView argument of this
method is used to connect the current view to the dialog. We will call the open method of this object later in the controller.
The onCloseDialog event handler is simply moved from the HelloPanel controller to the reuse object.
sap.ui.define([
"use strict";
// show message
},
this.getOwnerComponent().helloDialog.open(this.getView());
}
});
});
The onOpenDialog method now accesses its component by calling the helper method getOwnerComponent. When calling the open method of the reuse
object we pass in the current view to connect it to the dialog.
<mvc:View
xmlns="sap.m"
<pages>
<headerContent>
<Button
icon="sap-icon://hello-world"
press="onOpenDialog"/>
</headerContent>
<content>
</content>
</Page>
</pages>
</App>
</mvc:View>
We add a button to the header area of the app view to show the reuse of the hello world dialog. When pressing the button the dialog will be opened as with the
button that we previously created in the panel.
sap.ui.define([
"use strict";

}
});
});
We add the method onOpenDialog also to the app controller so that the dialog will open with a reference to the current view.
Conventions
Put all assets that are used across multiple controllers in separate modules.
Previous: Step 18: Icons
Next: Step 20: Aggregation Binding
1.3.2.20 Step 20: Aggregation Binding

Now that we have established a good structure for our app, it's time to add some more functionality. We start exploring more features of data binding by adding
some invoice data in JSON format that we display in a list below the panel.
Preview
Figure 1: A list of invoices is displayed below the panel
Coding
webapp/Invoices.json (New)
{
"Invoices": [
{
"ProductName": "Pineapple",
"Quantity": 21,
"ExtendedPrice": 87.2000,
"ShipperName": "Fun Inc.",
"ShippedDate": "2015-04-01T00:00:00",
"Status": "A"
},
{
"ProductName": "Milk",
"Quantity": 4,
"ShipperName": "ACME",
"ShippedDate": "2015-02-18T00:00:00",
"Status": "B"
},
{
"ProductName": "Canned Beans",
"Quantity": 3,
"ShippedDate": "2015-03-02T00:00:00",
"Status": "B"
},

{
"ProductName": "Salad",
"Quantity": 2,
"ShippedDate": "2015-04-12T00:00:00",
"Status": "C"
},
{
"ProductName": "Bread",
"Quantity": 1,
"ShippedDate": "2015-01-27T00:00:00",
"Status": "A"
}
]
}
The invoices file simply contains five invoices in a JSON format that we can use to bind controls against them in the app. JSON is a very lightweight format
for storing data and can be directly used as a data source for SAPUI5 applications.
{

"sap.ui5": {
"_version": "1.1.0",
"dependencies": {
"libs": {
"sap.m": {}
}
},
"models": {
"i18n": {
"settings": {
}
},
"invoice": {
"type": "sap.ui.model.json.JSONModel",
"uri": "Invoices.json"
}
}
}
}
We add a new model invoice to the sap.ui5 section of the descriptor. This time we want a JSONModel, so we set the type to
sap.ui.model.json.JSONModel. The uri key is the path to our test data relative to the component. With this little configuration our component will
automatically instantiate a new JSONModel which loads the invoice data from the Invoices.json file. Finally, the instantiated JSONModel is put onto the
component as a named model invoice. The named model is then visible throughout our app.
Note
Automatic model instantiation is only available as of SAPUI5 version 1.30. If you are using an older version, you can manually instantiate the resource
bundle and other models of the app in the onInit method of the Component.js file as we did for the resource bundle in Step 9: Component
Configuration.
<mvc:View
xmlns="sap.m"
displayBlock="true" >
<pages>
<headerContent>
<Button
</headerContent>
<content>

<mvc:XMLView viewName="sap.ui.demo.wt.view.InvoiceList"/>
</content>
</Page>
</pages>
</App>
</mvc:View>
In the app view we add a second view to display our invoices below the panel.
webapp/view/InvoiceList.view.xml (New)
<mvc:View
xmlns="sap.m"
<List
headerText="{i18n>invoiceListTitle}"
width="auto"
items="{invoice>/Invoices}" >
<items>
<ObjectListItem
title="{invoice>Quantity} x {invoice>ProductName}"/>
</items>
</List>
</mvc:View>
The new view is displaying a list control with a custom header text. The item aggregation of the list is bound to the root path Invoices of the JSON data.
And since we defined a named model, we have to prefix each binding definition with the identifier invoice>.
In the items aggregation, we define the template for the list that will be automatically repeated for each invoice of our test data. More precisely, we use an
ObjectListItem to create a control for each aggregated child of the items aggregation. The title property of the list item is bound to properties of a
single invoice. This is achieved by defining a relative path (without / in the beginning). This works because we have bound the items aggregation via
items={invoice>/Invoices} to the invoices.
# App Descriptor
# Hello Panel
helloMsg=Hello {0}
# Invoice List
invoiceListTitle=Invoices
In the text bundle the title of the list is added.
Previous: Step 19: Reuse Dialogs
Next: Step 21: Data Types
Related Information
Lists
Aggregation Binding
1.3.2.21 Step 21: Data Types

The list of invoices is already looking nice, but what is an invoice without a price assigned? Typically prices are stored in a technical format and with a '.'
delimiter in the data model. For example, our invoice for pineapples has the calculated price 87.2 without a currency. We are going to use the SAPUI5 data
types to format the price properly, with a locale-dependent decimal separator and two digits after the separator.
Preview

Figure 1: The list of invoices with prices and number units
Coding
webapp/view/InvoiceList.view.xml
<mvc:View
controllerName="sap.ui.demo.wt.controller.InvoiceList"
xmlns="sap.m"
<List
width="auto"
items="{invoice>/Invoices}">
<items>
<ObjectListItem
title="{invoice>Quantity} x {invoice>ProductName}"
number="{
parts: [{path: 'invoice>ExtendedPrice'}, {path: 'view>/currency'}],
type: 'sap.ui.model.type.Currency',
formatOptions: {
showMeasure: false
}
}"
numberUnit="{view>/currency}"/>
</items>
</List>
</mvc:View>
We add a price to our invoices list in the view by adding the number and numberUnit attributes to the ObjectListItem control, then we apply the
currency data type on the number by setting the type attribute of the binding syntax to sap.ui.model.type.Currency.
As you can see above, we are using a special binding syntax for the number property of the ObjectListItem. This binding syntax makes use of so-called
"Calculated Fields", which allows the binding of multiple properties from different models to a single property of a control. The properties bound from different
models are called parts. In the example above, the property of the control is number and the bound properties (parts) retrieved from two different models
are invoice>ExtendedPrice and view>/currency.
We want to display the price in Euro, and typically the currency is part of our data model on the back end. In our case this is not the case, so we need to
define it directly in the app. We therefore add a controller for the invoice list, and use the currency property as the second part of our binding syntax. The
Currency type will handle the formatting of the price for us, based on the currency code. In our case, the price is displayed with 2 decimals.
Additionally, we set the formatting option showMeasure to false. This hides the currency code in the property number, because it is passed on to the
ObjectListItem control as a separate property numberUnit.
webapp/controller/InvoiceList.controller.js (New)
webapp/controller/InvoiceList.controller.js (New)
sap.ui.define([
], function (Controller, JSONModel) {
"use strict";
return Controller.extend("sap.ui.demo.wt.controller.InvoiceList", {
var oViewModel = new JSONModel({
currency: "EUR"
});
this.getView().setModel(oViewModel, "view");
}
});
});
To be able to access the currency code that is not part of our data model, we define a view model in the controller of the invoice list. It is a simple JSON
model with just one key currency and the value EUR. This can be bound to the formatter of the number field. View models can hold any configuration options
assigned to a control to bind properties such as the visibility.
Conventions
Use data types instead of custom formatters whenever possible.
Previous: Step 20: Aggregation Binding
Next: Step 22: Expression Binding
Related Information
Calculated Fields for Data Binding
Custom Formatter Functions

Sometimes the predefined types of SAPUI5 are not flexible enough and you want to do a simple calculation or formatting in the view - that is where
expressions are really helpful. We use them to format our price according to the current number in the data model.
Preview

Figure 1: The price is now formatted according to its number
Coding
<mvc:View
xmlns="sap.m"
<List
width="auto"
<items>
<ObjectListItem
number="{
formatOptions: {
showMeasure: false
}
}"
numberUnit="{view>/currency}"
numberState="{= ${invoice>ExtendedPrice} > 50 ? 'Error' : 'Success' }"/>
</items>
</List>
</mvc:View>
We add the property numberState in our declarative view and introduce a new binding syntax that starts with = inside the brackets. This symbol is used to
initiate a new binding syntax, it's called an expression and can do simple calculation logic like the ternary operator shown here.
The condition of the operator is a value from our data model. A model binding inside an expression binding has to be escaped with the $ sign as you can see
in the code. We set the state to 'Error' (the number will appear in red) if the price is higher than 50 and to Success (the number will appear in green)
otherwise.
Expressions are limited to a particular set of operations that help formatting the data such as Math expression, comparisons, and such. You can lookup the
possible operations in the documentation.
Conventions
Conventions
Only use expression binding for trivial calculations.
Previous: Step 21: Data Types
Next: Step 23: Custom Formatters
Related Information
Expression Binding
1.3.2.23 Step 23: Custom Formatters

If we want to do a more complex logic for formatting properties of our data model, we can also write a custom formatting function. We will now add a localized
status with a custom formatter, because the status in our data model is in a rather technical format.
Preview
Figure 1: A status is now displayed with a custom formatter
Coding
webapp/model/formatter.js (New)
sap.ui.define([], function () {
"use strict";
return {
statusText: function (sStatus) {
var resourceBundle = this.getView().getModel("i18n").getResourceBundle();
switch (sStatus) {
case "A":
return resourceBundle.getText("invoiceStatusA");
case "B":
return resourceBundle.getText("invoiceStatusB");

case "C":
return resourceBundle.getText("invoiceStatusC");
default:
return sStatus;
}
}
};
});
Our new formatter file is located in the model folder of the app, because formatters are working on data properties and format them for display on the UI. So
far we did not have any model-related artifacts, except for the Invoices.json file, we will now add the folder webapp/model to our app. This time we do
not extend from any base object but just return a JavaScript object with our formatter functions inside the sap.ui.define call.
As the JSDoc comment block in front of the function says, the function statusText gets the technical status from the data model as input parameter and
returns a human-readable text that is read from the resourceBundle file.
webapp/controller/InvoiceList.controller.js
sap.ui.define([
"sap/ui/demo/wt/model/formatter"
], function (Controller, JSONModel, formatter) {
"use strict";
formatter: formatter,
currency: "EUR"
});
}
});
});
To load our formatter functions, we have to add it to the InvoiceList.controller.js. In this controller, we first add a dependency to our custom
formatter module. The controller simply stores the loaded formatter functions in the local property formatter to be able to access them in the view.
<mvc:View
xmlns="sap.m"
<List
width="auto"
items="{invoice>/Invoices}">
<items>
<ObjectListItem
number="{
formatOptions: {
showMeasure: false
}
}"
numberState="{= ${invoice>ExtendedPrice} > 50 ? 'Error' : 'Success' }">
<firstStatus>
<ObjectStatus text="{
path: 'invoice>Status',
formatter: '.formatter.statusText'
}"/>
</firstStatus>
</ObjectListItem>
</items>
</List>
</mvc:View>
We add a status using the firstStatus aggregation to our ObjectListItem that will display the status of our invoice. The custom formatter function is
specified with the reserved property formatter of the binding syntax. A "." in front of the formatter name means that the function is looked up in the
controller of the current view. There we defined a property formatter that holds our formatter functions, so we can access it by
.formatter.statusText.
webapp/i18n/i18.properties

webapp/i18n/i18.properties
# App Descriptor
# Hello Panel
helloMsg=Hello {0}
# Invoice List
invoiceStatusA=New
invoiceStatusB=In Progress
invoiceStatusC=Done
We add three new entries to the resource bundle that reflect our translated status texts. These texts are now displayed below the number attribute of the
ObjectListItem dependent on the status of the invoice.
Next Step
Continue with Step 24: Filtering.
Previous: Step 22: Expression Binding
Next: Step 24: Filtering
Related Information
Using Complex Syntax to Define a Formatter
1.3.2.24 Step 24: Filtering

In this step, we add a search field for our product list and define a filter that represents the search term. When searching, the list is automatically updated to
show only the items that match the search term.
Preview

Figure 1: A search field is displayed above the list
Coding
<mvc:View
xmlns="sap.m"
<List
id="invoiceList"
width="auto"
<headerToolbar>
<Toolbar>
<Title text="{i18n>invoiceListTitle}"/>
<ToolbarSpacer/>
<SearchField width="50%" search="onFilterInvoices" selectOnFocus="false"/>
</Toolbar>
</headerToolbar>
<items>
<ObjectListItem>

</ObjectListItem/>
</items>
</List>
</mvc:View>
The view is extended by a search control that we add to the list of invoices. We also need to specify an ID invoiceList for the list control to be able to
identify the list from the event handler function onFilterInvoices that we add to the search field. In addition, the search field is part of the list header and
therefore, each change on the list binding will trigger a rerendering of the whole list, including the search field. Since we want the cursor to stay at the same
position, we set the flag selectOnFocus to false.
The headerToolbar aggregation replaces the simple title property that we used before for our list header. A toolbar control is way more flexible and can
be adjusted as you like. We are now displaying the title on the left side with a sap.m.Title control, a spacer, and the sap.m.SearchField on the right.
sap.ui.define([

"sap/ui/demo/wt/model/formatter",
"sap/ui/model/Filter",
"sap/ui/model/FilterOperator"
], function (Controller, JSONModel, formatter, Filter, FilterOperator) {
"use strict";
formatter: formatter,
currency: "EUR"
});
},
onFilterInvoices : function (oEvent) {
// build filter array

var aFilter = [];
var sQuery = oEvent.getParameter("query");
if (sQuery) {
aFilter.push(new Filter("ProductName", FilterOperator.Contains, sQuery));
}
// filter binding
var oList = this.getView().byId("invoiceList");
var oBinding = oList.getBinding("items");
oBinding.filter(aFilter);
}
});
});
We load two new dependencies for the filtering. The filter object will hold our configuration for the filter action and the FilterOperator is a helper type that
we need in order to specify the filter.
In the onFilterInvoices function we construct a filter object from the search string that the user has typed in the search field. Event handlers always
receive an event argument that can be used to access the parameters that the event provides. In our case the search field defines a parameter query that we
access by calling getParameter(query) on the oEvent parameter.
If the query is not empty, we add a new filter object to the still empty array of filters. However, if the query is empty, we filter the binding with an empty array.
This makes sure that we see all list elements again. We could also add more filters to the array, if we wanted to search more than one data field. In our
example, we just search in the ProductName path and specify a filter operator that will search for the given query string.
The list is accessed with the ID that we have specified in the view, because the control is automatically prefixed by the view ID, we need to ask the view for
the control with the helper function byId. On the list control we access the binding of the aggregation items to filter it with our newly constructed filter object.
This will automatically filter the list by our search string so that only the matching items are shown when the search is triggered. The filter operator
FilterOperator.Contains is not case-sensitive.
Previous: Step 23: Custom Formatters
Next: Step 25: Sorting and Grouping
1.3.2.25 Step 25: Sorting and Grouping

To make our list of invoices even more user-friendly, we sort it alphabetically instead of just showing the order from the data model. Additionally, we introduce
groups and add the company that ships the products so that the data is easier to consume.
Preview

Figure 1: The list is now sorted and grouped by the shipping company
Coding
<mvc:View
xmlns="sap.m"
<List
id="invoiceList"
width="auto"
items="{
path : 'invoice>/Invoices',
sorter : {
path : 'ProductName'
}
}" >
<headerToolbar>
...
</headerToolbar>
<items>
...
</items>
</List>
</mvc:View>
We add a declarative sorter to our binding syntax. As usual, we transform the simple binding syntax to the object notation, specify the path to the data, and
now add an additional sorter property. We specify the data path by which the invoice items should be sorted, the rest is done automatically. By default, the
sorting is ascending, but you could also add a property descending with the value true inside the sorter property to change the sorting order.
If we run the app now we can see a list of invoices sorted by the name of the products.

<mvc:View
xmlns="sap.m"
<List
id="invoiceList"
width="auto"
items="{
sorter : {
path : 'ShipperName',
group : true
}
}">
<headerToolbar>
<Toolbar>
<ToolbarSpacer/>
<SearchField width="50%" search="onFilterInvoices"/>
</Toolbar>
</headerToolbar>
<items>

</items>
</List>
</mvc:View>
We modify the view and add a different sorter, or better; we change the sorter and set the attribute group to true. We also specify the path to the
ShipperName data field. This groups the invoice items by the shipping company.
As with the sorter, no further action is required. The list and the data binding features of SAPUI5 will do the trick to display group headers automatically and
categorize the items in the groups. We could define a custom grouping function if we wanted by setting the groupHeaderFactory property, but the result
looks already fine.
Previous: Step 24: Filtering
Next: Step 26: Remote OData Service
1.3.2.26 Step 26: Remote OData Service

So far we have only worked with local JSON data, but now we will access a real OData service. Instead of implementing an own OData service we will simply
use the publicly available Northwind OData service to visualize remote data. You will be surprised how little needs to be changed in order to make this work!
Preview

Figure 1: Products from the OData invoices test service are now shown within our app
Coding
{
"_version": "1.1.0",
"sap.app": {
...
"ach": "CA-UI5-DOC",
"dataSources": {
"invoiceRemote": {
"uri": "https://services.odata.org/V2/Northwind/Northwind.svc/",
"type": "OData",
"settings": {
"odataVersion": "2.0"
}
}
}
},
"sap.ui": {
...
},
"sap.ui5": {
"_version": "1.1.0",
"dependencies": {
"libs": {
"sap.m": {}
}
},

"models": {
"i18n": {
"settings": {
}
},
"invoice": {
"dataSource": "invoiceRemote"
}
}
}
}
In the sap.app section of the descriptor file, we add a data source configuration. With the invoiceRemote, key we specify a configuration object that
allows automatic model instantiation. We specify the type of the service (OData) and the model version (2.0). In this step, we want to use the publicly
available Northwind OData service located at https://services.odata.org/V2/Northwind/Northwind.svc/. Therefore, the URI points to the
official Northwind OData service.
Note
We are referencing the Northwind OData service via HTTPS. However, the certificate might not be trusted. Thus, make sure that you call the URL
https://services.odata.org/V2/Northwind/Northwind.svc/ directly in your browser and accept the certificate once, before you continue.
In the models section, we replace the content of the invoice model. This key is still used as model name when the model is automatically instantiated
during the component initialization. However, the invoiceRemote value of the dataSource key is a reference to the data source section that we specified
above. This configuration allows the component to retrieve the technical information for this model during the start-up of the app.
Our component now automatically creates an instance of sap.ui.model.odata.v2.ODataModel according to the settings we specified above, and
makes it available as model named invoice. If you want to have a default model on the component, you can change the name of the model to an empty
string in the descriptor file. Automatically instantiated models can be retrieved by calling this.getModel in the component. In the controllers of component-
based apps you can call this.getView().getModel() to get the automatically instantiated model. For retrieving a named model you have to pass on the
model name defined in the descriptor file to getModel, this means, in the component you would call this.getModel("invoice") to get our automatically
generated invoice model that we defined in the descriptor.
When using the data source invoiceRemote, the ODataModel fetches the data from the real Northwind OData service. The invoices we receive from the
Northwind OData service have identical properties as the JSON data we used previously (except for the status propertythat is not available in the Northwind
OData service).
You can now try to run the app and see what happens - we will see some errors in the browsers console:
Figure 2: Violations of the same-origin policy in Google Chrome
Note
Due to the so called same-origin policy, browsers deny AJAX requests to service endpoints in case the domain/subdomain, protocol, or port differ from the
apps domain/subdomain, protocol, or port.
The browser refuses to connect to a remote URL directly for security reasons and we need a workaround.
For productive apps this approach is not recommended we will describe the options later in this step.
Tip
In Google Chrome, you can easily disable same-origin policy of Chrome by running Chrome with the following command: [here-your-path-to-
chrome-installation-dir]\chrome.exe --disable-web-security. Make sure that all instances of Chrome are closed before you run the
command above. This will allow all Web sites to break out of the same-origin policy and connect to the remote service directly. Be aware that its a
security risk in case you run Chrome this way for surfing on the internet. However, it also allows you to avoid the need of setting up a proxy at
development time or for testing purposes
After disabling the same-origin policy in your browser, you can now run the app again. This time you can see all kinds of invoices retrieved from a real back
end. In case you still have issues, just continue with the next step. There, we will switch to local mock data.
Note
In the component, we have added a dependency to sap.ui.model.odata.v2.ODataModel. The v2 in the namespace stands for the second version
of the ODataModel implementation in SAPUI5. This v2 is not related to the "OData Version 2" specification. We recommend suggested to use the new
implementation sap.ui.model.odata.v2.ODataModel instead of the old sap.ui.model.odata.ODataModel in your SAPUI5 apps.
Optional: Proxy Configuration to Avoid Same-Origin Policy Issues

In a real app scenario, the remote system would be configured to send the cross-origin resource sharing (CORS) headers to make the browser also allow direct
access to remote URLs. However, we cannot modify the publicly available Northwind OData service. Thus, when trying to execute XHR requests

(XMLHttpRequest) the browser will prevent the call due to the so called same-origin policy as we have experienced above.
In order to overcome these issues, we have the following options:
Deploy the app on the same server or domain as the service we want to call, so that both resources are in the same origin
Set the CORS-relevant response headers on the remote system
Use a helper service from the same domain of our app as a proxy to call the real remote service
Disable same-origin policy in the browser for local testing
In the previous section we used the last approach which is not recommended for productive scenarios.
We will now switch to using a helper service as a proxy. For us, a proxy is simply a service end point on the same domain of our app to overcome the
restrictions described above. It receives requests from our app, forwards them to another server, and finally returns the corresponding response from the
remote service.
SAP Web IDE and the SAP HANA Cloud Platform offer so-called destinations that allow to easily connect to remote systems. The destination to our
Northwind OData service is an internet proxy made available inside the app at <protocol>://<domain>/destinations/northwind/*. Any request
that is sent to this location will be forwarded to http://services.odata.org automatically.
Here are a few examples:
Table 1: Examples for requests
Requested URL Forwarded To
/destinations/northwind/V2/Northwind/Northwind.svc/$metadata http://services.odata.org/V2/Northwind/Northwind.svc/$metadata
/destinations/northwind/V2/Northwind/Northwind.svc/Invoices http://services.odata.org/V2/Northwind/Northwind.svc/Invoices
The destination itself is configured inside the SAP HANA Cloud Platform Cockpit. To set up the destination for the Northwind OData service follow the
configuration steps described under Create a Northwind Destination.
In the following, we describe how to use the destination in our app to connect to the Northwind OData service.
Note
This section is describing the setup for the SAP Web IDE only. If you are using a different development environment, you can either create a simple proxy
service by yourself or use an existing one.
neo-app.json for SAP Web IDE (new)

{
"routes": [
{
"path": "/destinations/northwind",
"target": {
"type": "destination",
"name": "northwind"
},
"description": "Northwind OData Service"
}
]
}
The neo-app.json file is needed for SAP Web IDE to make sure that the destination and the resource mapping are available in the app. It has to be located
in the root folder (webapp), on the same level as the user.project.json file that is automatically created.
If it does not exist yet, create the file and reference the Northwind destination there. Just copy the content of the code block above into that file and try to run
the app again.
Note
If the file already exists, for example, because you already created it to map the SAPUI5 resources as described in Step 2 of this tutorial, just append the
destination to the existing route definitions.
Now you can run the app even without disabling the same-origin policy in your browser. In other words, the app can be used by any user even without changing
the browser settings.
{
"_version": "1.1.0",
"sap.app": {
...
"dataSources": {
"invoiceRemote": {
"uri": "/destinations/northwind/V2/Northwind/Northwind.svc/",
"type": "OData",
"settings": {
"odataVersion": "2.0"
}
}
}
},
"sap.ui": {

...
},
"sap.ui5": {
...
}
}
In the descriptor file, we change the invoiceRemote data source to use the Northwind destination. After this change, you can run the app in the SAP Web
IDE even without disabling the same-origin policy of your browser. The destination now manages the connection to the remote service.
Previous: Step 25: Sorting and Grouping
Next: Step 27: Mock Server Configuration
Related Information
Use a SimpleProxyServlet for Testing to Avoid Cross-domain Requests
OData Home Page
1.3.2.27 Step 27: Mock Server Configuration

We just ran our app against a real service, but for developing and testing our app we do not want to rely on the availability of the real service or put additional
load on the system where the data service is located. This system is the so-called back-end system that we will now simulate with a SAPUI5 feature called
mock server. It serves local files, but it simulates a back-end system more realistically than just loading the local data. We will also change the model
instantiation part so that the model is configured in the descriptor and instantiated automatically by SAPUI5. This way, we do not need to take care of the
model instantiation in the code.
Preview
Figure 1: The list of invoices is now served by the Mock Server
Coding

The folder structure of our app project is clearly separating test and productive files after this step. The new test folder now contains a new HTML page
mockServer.html which will launch our application in test mode without calling the real service.
The new localService folder contains a metadata.xmlservice description file for OData, the mockserver.js file that simulates a real service with local
data, and the mockdata subfolder that contains the local test data (Invoices.json).
webapp/test/mockServer.html (New)
<!DOCTYPE html>
<html>
<head>
<script
}' >
</script>
<script>
new sap.m.Shell({
app : new sap.ui.core.ComponentContainer({
name : "sap.ui.demo.wt",
height : "100%"
})
});
</script>
</head>
</body>
</html>
We copy the index.html to a separate file in the webapp/test folder and name it mockServer.html. We will now use this file to run our app in test
mode with mock data loaded from a JSON file. Test pages should not be placed in the application root folder but in a test folder to clearly separate productive
and test coding.
From this point on, you have two different entry pages: One for the real connected app (index.html) and one for local testing (mockServer.html). You
can freely decide if you want to do the next steps on the real service data or on the local data within the app.
Note
If no connection to the real service is available or the proxy configuration from the previous step does not work, you can always use the
mockServer.html file. This will display the app with simulated test data. The index.html file will always load the data from a remote server. If the
request fails, the list of invoices will stay empty.
webapp/test/mockServer.html

<!DOCTYPE html>
<html>
<head>
<title>Walkthrough - Test page</title>
<script
"sap.ui.demo.wt": "../"
}'>
</script>
<script>
sap.ui.require([
"sap/ui/demo/wt/localService/mockserver",
"sap/m/Shell",
"sap/ui/core/ComponentContainer"
], function (mockserver, Shell, ComponentContainer) {
mockserver.init();
new Shell({
app : new ComponentContainer({
height: "100%",
name: "sap.ui.demo.wt"
})
});
});
</script>
</head>
</body>
</html>
We modify the mockServer.html file and change the page title to distinguish it from the productive start page. In the bootstrap the data-sap-ui-
resourceroots property is also changed slightly because the mockServer.html file is not directly inside the webapp folder anymore.
Additionally, we switch the initialization of the component to the sap.ui.require syntax, because we do now load more additional files required for the
startup of our app. The first dependency is a file called mockserver.js that will be located in the localService folder later. We also switch to the
dependencies provided by the require statement for instantiating a Shell and ComponentContainer instead of using full namespaces to sap.m.
Shell and sap.ui.core.ComponentContainer.
The new mockserver.js resource that we just loaded and are about to implement is our local test server. Its init method is immediately called before we
actually define the component. This way we can catch all requests that would go to the real service and process them locally by our test server when
launching the app with the mockServer.html file. The component itself does not "know" that it will now run in test mode.
webapp/localService/mockdata/Invoices.json (New)
[
{
"ProductName": "Pineapple",
"Quantity": 21,
"ShippedDate": "2015-04-01T00:00:00",
"Status": "A"
},
{
"ProductName": "Milk",
"Quantity": 4,
"ShippedDate": "2015-02-18T00:00:00",
"Status": "B"
},
{
"ProductName": "Canned Beans",
"Quantity": 3,
"ShippedDate": "2015-03-02T00:00:00",

"Status": "B"
},
{
"ProductName": "Salad",
"Quantity": 2,
"ShippedDate": "2015-04-12T00:00:00",
"Status": "C"
},
{
"ProductName": "Bread",
"Quantity": 1,
"ShippedDate": "2015-01-27T00:00:00",
"Status": "A"
}
]
The Invoices.json file is similar to our previous file in the webapp folder. Just copy the content and remove the outer object structure with the key
invoices so that the file consists of one flat array of invoice items. This file will automatically be read by our server later in this step.
Remove the old Invoices.json file from the webapp folder, it is no longer used.
webapp/localService/metadata.xml (New)
<edmx:Edmx Version="1.0" xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx">
<edmx:DataServices m:DataServiceVersion="1.0" m:MaxDataServiceVersion="3.0"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<Schema Namespace="NorthwindModel" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
<EntityType Name="Invoice">
<Key>
<PropertyRef Name="ProductName"/>
<PropertyRef Name="Quantity"/>
<PropertyRef Name="ShipperName"/>
</Key>
<Property Name="ShipperName" Type="Edm.String" Nullable="false" MaxLength="40" FixedLength="false"
Unicode="true"/>
<Property Name="ProductName" Type="Edm.String" Nullable="false" MaxLength="40" FixedLength="false"
Unicode="true"/>
<Property Name="Quantity" Type="Edm.Int16" Nullable="false"/>
<Property Name="ExtendedPrice" Type="Edm.Decimal" Precision="19" Scale="4"/>
</EntityType>
</Schema>
<Schema Namespace="ODataWebV2.Northwind.Model" xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
<EntityContainer Name="NorthwindEntities" m:IsDefaultEntityContainer="true" p6:LazyLoadingEnabled="true"
xmlns:p6="http://schemas.microsoft.com/ado/2009/02/edm/annotation">
<EntitySet Name="Invoices" EntityType="NorthwindModel.Invoice"/>
</EntityContainer>
</Schema>
</edmx:DataServices>
</edmx:Edmx>
The metadata file contains information about the service interface and does not need to be written manually. It can be accessed directly from the real service
by calling the service URL and adding $metadata at the end (e.g. in our case
http://services.odata.org/V2/Northwind/Northwind.svc/$metadata). The mock server will read this file to simulate the real OData service,
and will return the results from our local source files in the proper format so that it can be consumed by the app (either in XML or in JSON format).
For simplicity, we have removed all content from the original Northwind OData metadata document that we do not need in our scenario. We have also added
the status field to the metadata since it is not available in the real Northwind service.
webapp/localService/mockserver.js (New)
sap.ui.define([
"sap/ui/core/util/MockServer"
], function (MockServer) {
"use strict";
return {
init: function () {
// create
var oMockServer = new MockServer({
rootUri: "/destinations/northwind/V2/Northwind/Northwind.svc/"
});
var oUriParameters = jQuery.sap.getUriParameters();
// configure
MockServer.config({
autoRespond: true,
autoRespondAfter: oUriParameters.get("serverDelay") || 1000
});

// simulate
var sPath = jQuery.sap.getModulePath("sap.ui.demo.wt.localService");
oMockServer.simulate(sPath + "/metadata.xml", sPath + "/mockdata");
// start
oMockServer.start();
}
};
});
Now that we have added the OData service description file metadata.xml file, we can write the code to initialize the mock server which will then simulate
any OData request to the real Northwind server.
We load the MockServer module as a dependency and create a helper object that defines an init method to start the server. This method is called before
the component initialization in the mockServer.html file above. The init method creates a MockServer instance with the same URL as the real service
calls.
The URL in configuration parameter rootURI will now be served by our test server instead of the real service. It matches the URL of our data source in the
descriptor file. Next, we set two global configuration settings that tell the server to respond automatically and introduce a delay of one second to imitate a
typical server response time. Otherwise, we would have to call the respond method on the MockServer manually to simulate the call.
To simulate a service, we can simply call the simulate method on the MockServer instance with the path to our newly created metadata.xml. This will
read the test data from our local file system and set up the URL patterns that will mimic the real service.
Finally, we call start on oMockServer. From this point, each request to the URL pattern rootURI will be processed by the MockServer. If you switch from
the index.html file to the mockServer.html file in the browser, you can now see that the test data is displayed from the local sources again, but with a
short delay. The delay can be specified with the URI parameter serverDelay, the default value is one second.
This approach is perfect for local testing, even without any network connection. This way your development does not depend on the availability of a remote
server, i.e. to run your tests.
Try calling the app with the index.html file and the mockServer.html file to see the difference. If the real service connection cannot be made, for
example when there is no network connection, you can always fall back to the local test page.
Note
The URI of the invoiceRemote data source in the descriptor points to our destination configured for SAP Web IDE (see previous step). We assume this
destination to be available. In any other development environment, you need to use a local proxy for the request to the service as described in the previous
step. This is important when you call the application with the index.html file, otherwise the call to the remote service will fail.
Conventions
The webapp/test folder contains non-productive code only.
Mock data and the script to start the MockServer are stored in the webapp/localService folder.
The script to start the MockServer is called mockserver.js.
Previous: Step 26: Remote OData Service
Next: Step 28: Unit Test with QUnit
Related Information
Mock Server
1.3.2.28 Step 28: Unit Test with QUnit

Now that we have a test folder in the app, we can start to increase our test coverage. Actually, every feature that we added to the app so far, would require a
separate test case. We have totally neglected this so far, so lets add a simple unit test for our custom formatter function from Step 23. We will test if the long
text for our status is correct by comparing it with the texts from our resource bundle.
Preview

Figure 1: A unit test for our formatters is now available
Coding
We add a new folder unit under the test folder and a model subfolder where we will place our formatter unit test. The folder structure matches the app
structure to easily find the corresponding unit tests.
webapp/test/unit/model/formatter.js
sap.ui.require(
[
"sap/ui/model/resource/ResourceModel",
"sap/ui/thirdparty/sinon",
"sap/ui/thirdparty/sinon-qunit"
],
function (formatter, ResourceModel) {
"use strict";
QUnit.module("Formatting functions", {
setup: function () {
this._oResourceModel = new ResourceModel({
bundleUrl : jQuery.sap.getModulePath("sap.ui.demo.wt", "/i18n/i18n.properties")
});
},
teardown: function () {
this._oResourceModel.destroy();
}
});
QUnit.test("Should return the translated texts", function (assert) {
// Arrange
var oViewStub = {
getModel: this.stub().withArgs("i18n").returns(this._oResourceModel)
};
var oControllerStub = {

getView: this.stub().returns(oViewStub)
};
// System under test
var fnIsolatedFormatter = formatter.statusText.bind(oControllerStub);
// Assert
assert.strictEqual(fnIsolatedFormatter("A"), "New", "The long text for status A is correct");
assert.strictEqual(fnIsolatedFormatter("B"), "In Progress", "The long text for status B is correct");
assert.strictEqual(fnIsolatedFormatter("C"), "Done", "The long text for status C is correct");
assert.strictEqual(fnIsolatedFormatter("Foo"), "Foo", "The long text for status Foo is correct");
});
}
);
We create a new formatter.js file under webapp/test/unit/model where the unit test for the custom formatter is implemented. The formatter file
that we want to test is loaded as a dependency. We also need a dependency to the ResourceModel, because we want to check if the translated texts are
correct. Additionally, we need to load SinonJS to create a stub for the dependencies in the formatter function.
The formatter file just contains one QUnit module for our formatter function. It instantiates our ResourceBundle with the localized texts in the setup function
and destroys it again in the teardown function. These functions are called before and after each test is executed.
Next is our unit test for the formatter function. In the implementation of the statusText function that we created in step 23 we access the
ResourceBundle with the following queued call: var resourceBundle = this.getView().getModel("i18n").getResourceBundle();.
Since we do not want to test the controller, the view, or the model functionality, we first remove the dependencies by replacing these calls with empty hulls
with the help of SinonJS and its stub method. This happens in the Arrange section of the unit test. SinonJS injects a stub method for all objects so we can
simply call this.stub() to create a new stub for any behavior we need to mock.
Test stubs are functions with pre-programmed behavior. They support the full SinonJS test spy API in addition to methods which can be used to alter the
stubs behavior. If this part is a bit confusing have a look at the official SinonJS documentation for test spies or ignore it for now, it will become clear later on.
Then we bind our stub to the statusText formatter by calling the bind function of JavaScript. The this pointer is now bound to our controller stub when
the function is invoked using the variable fnIsolatedFormatter and we can still pass in arguments as we like. This happens in the "system under test"
part of the test.
Finally we perform our assertions. We check each branch of the formatter logic by invoking the isolated formatter function with the values that we expect in the
data model (A, B, C, and everything else). We strictly compare the result of the formatter function with the hard-coded strings that we expect from the resource
bundle and give a meaningful error message if the test should fail. We hard-code the strings here to identify issues with the resource bundle properties. If a
property was missing, the test would still be successful if we check against the real value (that would be an empty string on both sides) from the resource
bundle.
webapp/test/unit/unitTests.qunit.html (New)
<!DOCTYPE html>
<html>
<head>
<title>Unit tests for Walkthrough</title>
<meta http-equiv='X-UA-Compatible' content='IE=edge'>
<script id="sap-ui-bootstrap"
"sap.ui.demo.wt": "../../",
"test.unit": "./"
}'>
</script>
<script>
jQuery.sap.require("sap.ui.qunit.qunit-css");
jQuery.sap.require("sap.ui.thirdparty.qunit");
jQuery.sap.require("sap.ui.qunit.qunit-junit");
jQuery.sap.require("sap.ui.qunit.qunit-coverage");
// model tests
jQuery.sap.require("test.unit.model.formatter");
</script>
</head>
<body>
<div id="content"></div>
<h1 id="qunit-header">Unit tests for Walkthrough</h1>
<h2 id="qunit-banner"></h2>
<h2 id="qunit-userAgent"></h2>
<div id="qunit-testrunner-toolbar"></div>
<ol id="qunit-tests"></ol>
<div id="qunit-fixture"></div>
</body>
</html>
The so-called QUnit test suite is an HTML page that triggers all QUnit tests for the application. Most of it is generating the layout of the result page that you
can see in the preview and we wont further explain these parts but focus on the application parts instead.
Lets start with the namespaces. Since we are now in the webapp/test/unit folder, we actually need to go up two levels to get the src folder again. This
namespace can be used inside the tests to load and trigger application functionality. The test.unit namespace is simply a reference to the current folder so
that all QUnit files can be loaded with the test namespace.
After requiring some basic QUnit functionality (for technical reasons we cannot do this asynchronously with our sap.ui.require syntax), we load and thus
execute our formatter. Other QUnit tests can be added here as well. If we now open the webapp/test/service/unit/unitTests.qunit.html file in

the browser, we should see our test running and verifying the formatter logic.
Conventions
All unit tests are placed in the webapp/test/unit folder of the app.
Files in the test suite end with *.qunit.html.
The unitTests.qunit.html file triggers all unit tests of the app.
A unit test should be written for formatters, controller logic, and other individual functionality.
All dependencies are replaced by stubs to test only the functionality in scope.
Previous: Step 27: Mock Server Configuration
Next: Step 29: Integration Test with OPA
Related Information
QUnit Testing Fundamentals
QUnit Home Page
Sinon.JS Home Page
1.3.2.29 Step 29: Integration Test with OPA

If we want to test interaction patterns or more visual features of our app, we can also write an integration test. We havent thought about testing our interaction
with the app yet, so in this step we will check if the dialog actually opens when we click the Say Hello with Dialog button. We can easily do this with OPA5, a
feature of SAPUI5 that is easy to set up and is based on JavaScript and QUnit. Using integration and unit tests and running them consistently in a continuous
integration (CI) environment, we can make sure that we dont accidentally break our app or introduce logical errors in existing code.
Preview
Figure 1: An OPA test opens the "Hello" dialog from step 16
Coding

We add a new folder integration below the test folder, where we put our new test cases. Page objects that help structuring such integration tests are put
in the pages subfolder that we also create now.
webapp/test/integration/navigationJourney.js (New)
sap.ui.require([
"sap/ui/test/opaQunit"
], function () {
"use strict";
QUnit.module("Navigation");
opaTest("Should open the hello dialog", function (Given, When, Then) {
// Arrangements
Given.iStartMyAppInAFrame(jQuery.sap.getResourcePath("sap/ui/demo/src/test", ".html"));
//Actions
When.onTheAppPage.iPressTheSayHelloWithDialogButton();
// Assertions
Then.onTheAppPage.iShouldSeeTheHelloDialog().
and.iTeardownMyAppFrame();
});
});
Lets start with the journey first. A journey consists of a series of integration tests that belong to the same context such as navigating through the app.
Similar to the QUnit test implementation, OPA5 uses QUnit, that's why we first set up a QUnit module Navigation that will be displayed on our result page.
The function opaTest is the main aspect for defining integration tests with OPA. Its parameters define a test name and a callback function that gets
executed with the following OPA5 helper objects to write meaningful tests that read like a user story.
Given
On the given object we can call arrangement functions like iStartMyAppInAFrame to load our app in a separate iFrame for integration testing.
When
Contains custom actions that we can execute to get the application in a state where we can test the expected behavior.
Then
Contains custom assertions that check a specific constellation in the application and the teardown function that removes our iFrame again.
In our test, we create a very simple test that starts the test page in an iFrame. In the app, we trigger a click a button and expect that the dialog is opened
afterwards. Finally, we remove the iFrame again from our test page.
As you can see, the test case reads like a user story, we actually do not need the implementation of the methods yet to understand the meaning of the test
case. This approach is called "Behavior Driven Development" or simply BDD and is popular in "Agile Software Development".
webapp/test/integration/pages/App.js (New)
sap.ui.require([
"sap/ui/test/Opa5"
],
function (Opa5) {
"use strict";
Opa5.createPageObjects({
onTheAppPage: {
actions: {
iPressTheSayHelloWithDialogButton: function () {
return this.waitFor({
controlType: "sap.m.Button",
success: function (aButtons) {
aButtons[0].$().trigger("tap");

},
errorMessage: "Did not find the helloDialogButton button on the app page"
});
}
},
assertions: {
iShouldSeeTheHelloDialog: function () {
return this.waitFor({
controlType: "sap.m.Dialog",
success: function () {
// we set the view busy, so we need to query the parent of the app
Opa5.assert.ok(true, "The dialog is open");
},
errorMessage: "Did not find the dialog control"
});
}
}
}
});
});
The implementation of the page object holds the helper functions we just called in our journey. We require OPA5 from the sap.ui.test namespace and
define a page object with the helper function createPageObjects. We pass in an object with the key of our page onTheAppPage and two sections:
actions and assertions.
In the actions section of the page object we define a function to click the "Hello" dialog button. This is done in OPA5 with a waitFor statement, it is basically
a loop that checks for the conditions defined as parameters. If the conditions are met, the success callback is executed, if the test fails because the
conditions have not been met, the text in the errorMessage property is displayed on the result page.
We define a waitFor statement that checks for controls of type sap.m.Button. As soon as a button is found on the app page the success handler is
executed and we use jQuery to trigger a tap event on the first button that we found. This should open the HelloDialog similar to clicking on the button
manually.
In the assertions section we define another waitFor statement that checks if a sap.m.Dialog control is existing in the DOM of the app. When the dialog
has been found, the test is successful and we can immediately confirm by calling an ok statement with a meaningful message.
webapp/test/integration/opaTests.qunit.html (New)
<!DOCTYPE html>
<html>
<head>
<title>OPA tests for Walkthrough</title>
<meta http-equiv='X-UA-Compatible' content='IE=edge'>
<script id="sap-ui-bootstrap"
"sap.ui.demo.wt.test.integration": "./",
"sap.ui.demo.src.test" : "../../test/mockServer"
}'>
</script>
<script>
jQuery.sap.require("sap.ui.qunit.qunit-css");
jQuery.sap.require("sap.ui.thirdparty.qunit");
jQuery.sap.require("sap.ui.qunit.qunit-junit");
jQuery.sap.require("sap.ui.test.opaQunit");
jQuery.sap.require("sap.ui.test.Opa5");
// pages
jQuery.sap.require("sap.ui.demo.wt.test.integration.pages.App");
// journeys
jQuery.sap.require("sap.ui.demo.wt.test.integration.navigationJourney");
</script>
</head>
<body>
<div id="content"></div>
<div id="qunit"></div>
<div id="qunit-fixture"></div>
</body>
</html>
This file contains our test suite for all OPA tests of the app. We define a namespace to the current folder for our integration tests and to the mockServer
page so that we can easily start the app by this namespace instead of giving the file name directly in each test.
Then we load the basic QUnit and OPA functionality from SAPUI5 and our custom page object so that we can execute the test journey. The
navigationJourney we defined above is also loaded and the test functions inside are immediately executed.
When you call the webapp/test/integration/opaTests.qunit.html page of your project on the server, you should see the QUnit layout and a test
Should see the hello dialog is executed immediately. It will load the app in a small iFrame in the lower right of the page. There you can see what operations
the test is performing on the app, if everything works correctly the button click is triggered, then a dialog is shown and the test case is green.
Conventions

OPA tests are located in the webapp/test/integration folder of the application.
Use page objects and journeys for structuring OPA tests.
Previous: Step 28: Unit Test with QUnit
Next: Step 30: Debugging Tools
Related Information
Integration Testing with One Page Acceptance Tests (OPA5)
1.3.2.30 Step 30: Debugging Tools

Even though we have added a basic test coverage in the previous steps, it seems like we accidentally broke our app, because it does not display prices to our
invoices anymore. We need to debug the issue and fix it before someone finds out. Luckily, SAPUI5 provides a couple of debugging tools that we can use
within the app to check the application logic and the developer tools of modern browsers are also quite good. We will now check for the root cause.
Preview
Figure 1: The diagnostics window
Coding
<mvc:View
xmlns="sap.m"
<List
id="invoiceList"
width="auto"
items="{
sorter : {
group : true
}
}">
<headerToolbar>
<Toolbar>
<ToolbarSpacer/>

</Toolbar>
</headerToolbar>
<items>
<ObjectListItem
number="{
parts: [{path: 'invoice>ExTendedPrice'}, {path: 'view>/currency'}],
formatOptions: {
showMeasure: false
}
}"
numberState="{= ${invoice>ExtendedPrice} > 50 ? 'Error' : 'Success' }">
<attributes>
<ObjectAttribute text="{
}"/>
</attributes>
</ObjectListItem>
</items>
</List>
</mvc:View>
We introduced a typo in the binding of the number attribute to simulate a frequent error; instead of using 'invoice>ExtendedPrice' we use
'invoice>ExTendedPrice'. Now we call the app and notice that the price is actually missing. By pressing CTRL + ALT + SHIFT + S we open the
SAPUI5 support diagnostics tool and check the app.
Note
If you use the Google Chrome browser, you can install the UI5 Inspector plugin. With this plugin, you can easily debug your SAPUI5- or -based apps. For
more information, see UI5 Inspector.
Besides technical information about the app and a trace that is similar to the developer tools console of the browser, there is a really handy tool for checking
such errors in this dialog. Open the tab Control Tree by clicking on the expand symbol on the right.
A hierarchical tree of SAPUI5 controls is shown on the left and the properties of the selected control are displayed on the right. If we now select the first
ObjectListItem control of the tree and go to the Binding Infos tab on the right, we can actually see that the binding path of the number attribute is marked
as invalid. We can now correct the error in the view and the price should appear in the list of invoices again.
Sometimes errors are not as easy to spot and you actually need to debug the JavaScript code with the tools of the browser. For performance reasons, the
SAPUI5 files are shipped in a minified version, this means that all possible variable names are shortened and comments are removed.
This makes debugging harder because the code is a lot less readable. You can load the debug sources by adding the URL parameter sap-ui-debug=true
or by pressing CTRL + ALT + SHIFT + P and select Use Debug Sources in the dialog box that is displayed. After reloading the page, you can see in the
Network tab of the browsers developer tools that now a lot of files with the dbg suffix are loaded. These are the source code files that include comments
and the uncompressed code of the app and the SAPUI5 artifacts.
Figure 2: Information from CTRL + ALT + SHIFT + P
Conventions
As per SAPUI5 convention uncompressed source files end with *-dbg.js
Previous: Step 29: Integration Test with OPA
Next: Step 31: Routing and Navigation

Related Information
Debugging
Diagnostics Window
Technical Information Dialog
1.3.2.31 Step 31: Routing and Navigation

So far, we have put all app content on one single page. As we add more and more features, we want to split the content and put it on separate pages. In this
step, we will use the SAPUI5 navigation features to load and show a separate detail page that we can later use to display details for an invoice. In the previous
steps, we defined the page directly in the app view so that it is displayed when the app is loaded. We will now use the SAPUI5 router class to load the pages
and update the URL for us automatically. We specify a routing configuration for our app and create a separate view for each page of the app, then we connect
the views by triggering navigation events
Preview
Figure 1: A second page is added to display the invoice
Coding
{
"_version": "1.1.0",

"sap.ui5": {

"models": {

},
"routing": {
"config": {
"routerClass": "sap.m.routing.Router",
"viewType": "XML",
"viewPath": "sap.ui.demo.wt.view",
"controlId": "app",
"controlAggregation": "pages"
},
"routes": [
{
"pattern": "",
"name": "overview",
"target": "overview"
},
{
"pattern": "detail",
"name": "detail",
"target": "detail"
}
],
"targets": {
"overview": {
"viewName": "Overview"
},
"detail": {
"viewName": "Detail"
}
}
}
}

}
We add a new routing" section to the sap.ui5 part of the descriptor. There are three subsections that define the routing and navigation structure of the app:
config
This section contains the global router configuration and default values that apply for all routes and targets. We define the router class that we want to
use and where our views are located in the app. To load and display views automatically, we also specify which control is used to display the pages and
what aggregation should be filled when a new page is displayed.
routes
Each route defines a name, a pattern, and one or more targets to navigate to when the route has been hit. The pattern is basically the URL part that
matches to the route, we define two routes for our app. The first one is a default route that will show the overview page with the content from the
previous steps, and the second is the detail route with the URL pattern detail that will show a new page.
targets
A target defines a view that is displayed, it is associated with one or more routes and it can also be displayed manually from within the app. Whenever a
target is displayed, the corresponding view is loaded and shown in the app. In our app we simply define two targets with a view name that corresponds to
the target name.
webapp/Component.js
sap.ui.define([
"sap/ui/demo/wt/controller/HelloDialog",
], function (UIComponent, JSONModel, HelloDialog) {
"use strict";
metadata: {
manifest: "json"
},
init: function () {

// set dialog
// create the views based on the url/hash
this.getRouter().initialize();
}
});
});
In the component initialization method, we now add a call to initialize the router. We do not need to instantiate the router manually, it is automatically
instantiated based on our AppDescriptor configuration and assigned to the component.
Initializing the router will evaluate the current URL and load the corresponding view automatically. This is done with the help of the routes and targets that have
been configured in the AppDescriptor. If a route has been hit, the view of its corresponding target is loaded and displayed.
webapp/view/Overview.view.xml (New)
<mvc:View
xmlns="sap.m"
<headerContent>
<Button
</headerContent>
<content>
<mvc:XMLView viewName="sap.ui.demo.wt.view.InvoiceList"/>
</content>
</Page>
</mvc:View>
We move the content of the previous steps from the App view to a new Overview view. For simplicity, we do not change the controller as it only contains our
helper method to open the dialog, that means we reuse the controller sap.ui.demo.wt.controller.App for two different views (for the new overview and
for the app view). However, two instances of that controller are instantiated at runtime. In general, one instance of a controller is instantiated for each view that
references the controller.
<mvc:View
xmlns="sap.m"

<App class="nyAppDemoWT" id="app"/>
</mvc:View>
Our App view is now only containing the empty app tag. The router will automatically add the view that corresponds to the current URL into the app control.
The router identifies the app control with the ID that corresponds to the property controlId: app in the AppDescriptor.
webapp/view/Detail.view.xml (New)
<mvc:View
xmlns="sap.m"
<Page
title="{i18n>detailPageTitle}">
<ObjectHeader
title="Invoice"/>
</Page>
</mvc:View>
Now we add a second view for the detail view. It only contains a page and an ObjectHeader control that displays the static text Invoice for now.

# Invoice List
invoiceStatusA=New
invoiceStatusC=Done
# Detail Page
detailPageTitle=Walkthrough - Details
We add a new string to the resource bundle for the detail page title.
<mvc:View
xmlns="sap.m"
<List >

<items>
<ObjectListItem
number="{
formatOptions: {
showMeasure: false
}
}"
numberState="{= ${invoice>ExtendedPrice} > 50 ? 'Error' : 'Success' }"
type="Navigation"
press="onPress">
<firstStatus>
<ObjectStatus text="{
}"/>
</firstStatus>
</ObjectListItem>
</items>
</List>
</mvc:View>
In the invoice list view we add a press event to the list item and set the item type to Navigation so that the item can actually be clicked.
sap.ui.define([

"use strict";
onPress: function (oEvent) {

var oRouter = sap.ui.core.UIComponent.getRouterFor(this);
oRouter.navTo("detail");
}
});
});
We add the event handler function to the controller of our invoices list. Now it is time to navigate to the detail page by clicking an item in the invoice list. We
access the router instance for our app by calling the helper method sap.ui.core.UIComponent.getRouterFor(this). On the router we call the
navTo method to navigate to the detail route that we specified in the routing configuration.
You should now see the detail page when you click an item in the list of invoices.
Conventions
Define the routing configuration in the descriptor
Previous: Step 30: Debugging Tools
Next: Step 32: Routing with Parameters
Related Information
Routing and Navigation
Tutorial: Navigation and Routing
1.3.2.32 Step 32: Routing with Parameters

We can now navigate between the overview and the detail page, but the actual item that we selected in the overview is not displayed on the detail page yet. A
typical use case for our app is to show additional information for the selected item on the detail page. To make this work, we have to pass over the information
which item has been selected to the detail page and show the details for the item there.
Preview
Figure 1: The selected invoice details are now shown in the details page
Coding
{
"_version": "1.1.0",

"sap.ui5": {

"routing": {
"config": {
"viewType": "XML",
"viewPath": "sap.ui.demo.wt.view",
"controlId": "app",

"controlAggregation": "pages"
},
"routes": [
{
"pattern": "",
"name": "overview",
"target": "overview"
},
{
"pattern": "detail/{invoicePath}",
"name": "detail",
"target": "detail"
}
],
"targets": {
"overview": {
"viewName": "Overview"
},
"detail": {
"viewName": "Detail"
}
}
}
}
}
We now add a navigation parameter invoicePath to the detail route so that we can hand over the information for the selected item to the detail page.
Mandatory navigation parameters are defined with curly brackets.
webapp/view/Detail.view.xml
<mvc:View
controllerName="sap.ui.demo.wt.controller.Detail"
xmlns="sap.m"
<Page
title="{i18n>detailPageTitle}">
<ObjectHeader
intro="{invoice>ShipperName}"
title="{invoice>ProductName}"/>
</Page>
</mvc:View>
We add a controller that will take care of setting the items context on the view and bind some properties of the ObjectHeader to the fields of our invoice
model. We could add more detailed information from the invoice object here, but for simplicity reasons we just display two fields for now.
sap.ui.define([
"use strict";

onPress: function (oEvent) {

var oItem = oEvent.getSource();
oRouter.navTo("detail", {
invoicePath: oItem.getBindingContext("invoice").getPath().substr(1)
});
}
});
});
The control instance that has been interacted with can be accessed by the getSource method that is available for all SAPUI5 events. It will return the
ObjectListItem that has been clicked in our case. We will use it to pass the information of the clicked item to the detail page so that the same item can be
displayed there.
In the navTo method we now add a configuration object to fill the navigation parameter invoicePath with the current information of the item. This will update
the URL and navigate to the detail view at the same time. On the detail page, we can access this context information again and display the corresponding
item.
To identify the object that we selected, we would typically use the key of the item in the back-end system because it is short and precise. For our invoice
items however, we do not have a simple key and directly use the binding path to keep the example short and simple. The path to the item is part of the binding
context which is a helper object of SAPUI5 to manage the binding information for controls. The binding context can be accessed by calling the
getBindingContext method with the model name on any bound SAPUI5 control. We need to remove the first / from the binding path by calling

.substr(1) on the string because this is a special character in URLs and is not allowed, we will add it again on the detail page.
webapp/controller/Detail.controller.js (New)
sap.ui.define([
"use strict";
return Controller.extend("sap.ui.demo.wt.controller.Detail", {
onInit: function () {
oRouter.getRoute("detail").attachPatternMatched(this._onObjectMatched, this);
},
_onObjectMatched: function (oEvent) {
this.getView().bindElement({
path: "/" + oEvent.getParameter("arguments").invoicePath,
model: "invoice"
});
}
});
});
Our last piece to fit the puzzle together is the detail controller. It needs to set the context that we passed in with the URL parameter invoicePath on the
view, so that the item that has been selected in the list of invoices is actually displayed, otherwise, the view would simply stay empty.
In the init method of the controller we fetch the instance of our app router and attach to the detail route by calling the method attachPatternMatched on
the route that we accessed by its name. We register an internal callback function _onObjectMatched that will be executed when the route is hit, either by
clicking on the item or by calling the app with a URL for the detail page.
In the _onObjectMatched method that is triggered by the router we receive an event that we can use to access the URL and navigation parameters. The
arguments parameter will return an object that corresponds to our navigation parameters from the route pattern. We access the invoicePath that we set in
the invoice list controller and call the bindElement function on the view to set the context. We have to add the root / in front of the path again that was
removed for passing on the path as a URL parameter.
The bindElement function is creating a binding context for a SAPUI5 control and receives the model name as well as the path to an item in a configuration
object. This will trigger an update of the UI controls that we connected with fields of the invoice model. You should now see the invoice details on a separate
page when you click on an item in the list of invoices.
Conventions
Define the routing configuration in the AppDescriptor
Previous: Step 31: Routing and Navigation
Next: Step 33: Routing Back and History
Related Information
Tutorial: Navigation and Routing
1.3.2.33 Step 33: Routing Back and History

Now we can navigate to our detail page and display an invoice, but we cannot go back to the overview page yet. We'll add a back button to the detail page and
implement a function that shows our overview page again.
Preview
Figure 1: A back button is now displayed on the detail page
Coding

<mvc:View
xmlns="sap.m"
<Page
title="{i18n>detailPageTitle}"
showNavButton="true"
navButtonPress="onNavBack">
<ObjectHeader
title="{invoice>Quantity} x {invoice>ProductName}"/>
</Page>
</mvc:View>
On the detail page, we tell the control to display a back button by setting the parameter showNavButton to true and register an event handler that is called
when the back button is pressed.
webapp/controller/Detail.controller.js
sap.ui.define([
"sap/ui/core/routing/History"
], function (Controller, History) {
"use strict";
return Controller.extend("sap.ui.demo.wt.controller.Detail", {
},
_onObjectMatched: function (oEvent) {
this.getView().bindElement({
path: "/" + oEvent.getParameter("arguments").invoicePath,
model: "invoice"
});
},
onNavBack: function () {
var oHistory = History.getInstance();
var sPreviousHash = oHistory.getPreviousHash();
if (sPreviousHash !== undefined) {

window.history.go(-1);
} else {
oRouter.navTo("overview", true);
}
}
});
});
We load a new dependency that helps us to manage the navigation history from the sap.ui.core.routing namespace and add the implementation for the
event handler to our detail page controller.
In the event handler we access the navigation history and try to determine the previous hash. In contrast to the browser history, we will get a valid result only if
a navigation step inside our app has already happened. Then we will simply use the browser history to go back to the previous page. If no navigation has
happened before, we can tell the router to go to our overview page directly. The second parameter true tells the router to replace the current history state with
the new one since we actually do a back navigation by ourselves.
This implementation is a bit better than the browsers back button for our use case. The browser would simply go back one step in the history even though we
were on another page outside of the app. In the app, we always want to go back to the overview page even if we came from another link or opened the detail
page directly with a bookmark. You can try it by loading the detail page in a new tab directly and clicking on the back button in the app, it will still go back to
the overview page.
Conventions
Add a path to go back to the parent page when the history state is unclear.
Previous: Step 32: Routing with Parameters
Next: Step 34: Custom Controls
1.3.2.34 Step 34: Custom Controls

In this step, we are going to extend the functionality of SAPUI5 with a custom control. We want to rate the product shown on the detail page, so we create a
composition of multiple standard controls using the SAPUI5 extension mechanism and add some glue code to make them work nicely together. This way, we
can reuse the control across the app and keep all related functionality in one module.
Preview
Figure 1: A custom product rating control is added to the detail page
Coding
webapp/control/ProductRating.js (New)
sap.ui.define([
"sap/ui/core/Control"
], function (Control) {
"use strict";
return Control.extend("sap.ui.demo.wt.control.ProductRating", {
metadata : {
},
},
renderer : function (oRM, oControl) {
}
});
});
We create a new folder control and a file ProductRating.js that will hold our new control. As with our controllers and views, the custom control inherits
the common control functionality from a SAPUI5 base object, for controls this is done by extending the base class sap.ui.core.Control.
Custom controls are small reuse components that can be created within the app very easily. Due to their nature, they are sometimes also referred to as
"notepad or on the fly controls. A custom control is a JavaScript object that has two special sections (metadata and renderer) and a number of methods
that implement the functionality of the control.
The metadata section defines the data structure and thus the API of the control. With this meta information on the properties, events, and aggregations of
the control SAPUI5 automatically creates setter and getter methods and other convenience functions that can be called within the app.
The renderer defines the HTML structure that will be added to the DOM tree of your app whenever the control is instantiates in a view. It is usually called
initially by the core of SAPUI5 and whenever a property of the control is changed. The parameter oRM of the render function is the SAPUI5 render manager
that can be used to write strings and control properties to the HTML page.
The init method is a special function that is called by the SAPUI5 core whenever the control is instantiated. It can be used to set up the control and prepare
its content for display.
Note
Controls always extend sap.ui.core.Control and render themselves. You could also extend sap.ui.core.Element or
sap.ui.base.ManagedObject directly if you want to reuse life cycle features of SAPUI5 including data binding for objects that are not rendered.
Please refer to the API reference to learn more about the inheritance hierarchy of controls.
webapp/control/ProductRating.js
sap.ui.define([
"sap/ui/core/Control",
"sap/m/RatingIndicator",
"sap/m/Label",
"sap/m/Button"
], function (Control, RatingIndicator, Label, Button) {

"use strict";
return Control.extend("sap.ui.demo.wt.control.ProductRating", {
metadata : {
properties : {
value: {type : "float", defaultValue : 0}
},

aggregations : {
_rating : {type : "sap.m.RatingIndicator", multiple: false, visibility : "hidden"},
_label : {type : "sap.m.Label", multiple: false, visibility : "hidden"},
_button : {type : "sap.m.Button", multiple: false, visibility : "hidden"}
},
events : {
change : {
parameters : {
value : {type : "int"}
}
}
}
},
this.setAggregation("_rating", new RatingIndicator({
value: this.getValue(),
iconSize: "2rem",
visualMode: "Half",
liveChange: this._onRate.bind(this)
}));
this.setAggregation("_label", new Label({
text: "{i18n>productRatingLabelInitial}"
}).addStyleClass("sapUiTinyMargin"));
this.setAggregation("_button", new Button({
text: "{i18n>productRatingButton}",
press: this._onSubmit.bind(this)
}));
},
setValue: function (iValue) {

this.setProperty("value", iValue, true);
this.getAggregation("_rating").setValue(iValue);
},
_onRate : function (oEvent) {

var oRessourceBundle = this.getModel("i18n").getResourceBundle();
var fValue = oEvent.getParameter("value");
this.setValue(fValue);
this.getAggregation("_label").setText(oRessourceBundle.getText("productRatingLabelIndicator", [fValue, oEvent.getSource().getMa

this.getAggregation("_label").setDesign("Bold");
},
_onSubmit : function (oEvent) {

var oResourceBundle = this.getModel("i18n").getResourceBundle();
this.getAggregation("_rating").setEnabled(false);
this.getAggregation("_label").setText(oResourceBundle.getText("productRatingLabelFinal"));
this.getAggregation("_button").setEnabled(false);
this.fireEvent("change", {
value: this.getValue()
});
},
renderer : function (oRM, oControl) {
oRM.write("<div");
oRM.writeControlData(oControl);
oRM.addClass("myAppDemoWTProductRating");
oRM.writeClasses();
oRM.write(">");
oRM.renderControl(oControl.getAggregation("_rating"));
oRM.renderControl(oControl.getAggregation("_label"));
oRM.renderControl(oControl.getAggregation("_button"));
oRM.write("</div>");
}
});
});
We now enhance our new custom control with the custom functionality that we need. In our case we want to create an interactive product rating, so we define
a value and use three internal controls that are displayed updated by our control automatically. A RatingIndicator control is used to collect user input on
the product, a label is displaying further information, and a button submits the rating to the app to store it.
In the metadata section we therefore define several properties that we make use in the implementation:
Properties
Value
We define a control property value that will hold the value that the user selected in the rating. Getter and setter function for this property will
automatically be created and we can also bind it to a field of the data model in the XML view if we like.
Aggregations
As described in the first paragraph, we need three internal controls to realize our rating functionality. We therefore create three hidden aggregations by

setting the visibility attribute to hidden. This way, we can use the models that are set on the view also in the inner controls and SAPUI5 will take
care of the lifecycle management and destroy the controls when they are not needed anymore. Aggregations can also be used to hold arrays of controls
but we just want a single control in each of the aggregations so we need to adjust the cardinality by setting the attribute multiple to false.
_rating: A sap.m.RatingIndicator control for user input
_label: A sap.m.Label to display additional information
_button: A sap.m.Button to submit the rating
Note
You can define aggregations and associations for controls. The difference is in the relation between the parent and the related control:
An aggregation is a strong relation that also manages the lifecycle of the related control, for example, when the parent is destroyed, the
related control is also destroyed. Also, a control can only be assigned to one single aggregation, if it is assigned to a second aggregation, it is
removed from the previous aggregation automatically.
An association is a weak relation that does not manage the lifecycle and can be defined multiple times. To have a clear distinction, an
association only stores the ID, whereas an aggregation stores the direct reference to the control. We do not specify associations in this
example, as we want to have our internal controls managed by the parent.
Events
Change
We specify a change event that the control will fire when the rating is submitted. It contains the current value as an event parameter. Applications
can register to this event and process the result similar to regular SAPUI5 controls, which are in fact build similar to custom controls.
In the init function that is called by SAPUI5 automatically whenever a new instance of the control is instantiated, we set up our internal controls. We
instantiate the three controls and store them in the internal aggregation by calling the framework method setAggregation that has been inherited from
sap.ui.core.Control. We pass on the name of the internal aggregations that we specified above and the new control instances. We specify some control
properties to make our custom control look nicer and register a liveChange event to the rating and a press event to the button. The initial texts for the label
and the button are referenced from our i18n model.
Lets ignore the other internal helper functions and event handlers for now and define our renderer. With the help of the SAPUI5 render manager and the control
instance that are passed on as a reference, we can now render the HTML structure of our control. We render the start of the outer <div> tag as <div and call
the helper method writeControlData to render the ID and other basic attributes of the control inside the div tag. Next, we add a custom CSS class so
that we can define styling rules for the custom control in our CSS file later. This CSS class and others that have been added in the view are then rendered by
calling writeClasses on the renderer instance. Then we close the surrounding div tag and render three internal controls by passing the content of the
internal aggregation to the render managers renderControl function. This will call the renderer of the controls and add their HTML to the page. Finally, we
close our surrounding <div> tag.
The setValue is an overridden setter. SAPUI5 will generate a setter that updates the property value when called in a controller or defined in the XML view,
but we also need to update the internal rating control in the hidden aggregation to reflect the state properly. Also, we can skip the rerendering of SAPUI5 that is
usually triggered when a property is changed on a control by calling the setProperty method to update the control property with true as the third parameter.
Now we define the event handler for the internal rating control. It is called every time the user changes the rating. The current value of the rating control can be
read from the event parameter value of the sap.m.RatingIndicator control. With the value we call our overridden setter to update the control state, then
we update the label next to the rating to show the user which value he has selected currently and also displays the maximum value. The string with the
placeholder values is read from the i18n model that is assigned to the control automatically.
And last but not least, we have the press handler for the rating button that submits our rating. We assume that rating a product is a one-time action and first
disable the rating and the button so that the user is not allowed to submit another rating. We also update the label to show a "Thank You" message, then we
fire the change event of the control and pass in the current value as a parameter so that applications that are listening to this event can react on the rating
interaction.
<mvc:View
xmlns="sap.m"
xmlns:wt="sap.ui.demo.wt.control">
<Page
<ObjectHeader
title="{invoice>ProductName}"/>
<wt:ProductRating class="sapUiSmallMarginBeginEnd" change="onRatingChange"/>
</Page>
</mvc:View>
A new namespace wt is defined on the detail view so that we can reference our custom controls easily in the view. We then add an instance of the
ProductRating control to our detail page and register an event handler for the change event. To have a proper layout, we also add a margin style class.
sap.ui.define([
"sap/ui/core/routing/History",
], function (Controller, History, MessageToast) {
use strict;
return Controller.extend(sap.ui.demo.wt.controller.Detail, {


onNavBack: function () {

},
onRatingChange : function (oEvent) {
var fValue = oEvent.getParameter("value");
var oResourceBundle = this.getView().getModel("i18n").getResourceBundle();
MessageToast.show(oResourceBundle.getText("ratingConfirmation", [fValue]));
}
});
});
In the Detail controller we load the dependency to the sap.m.MessageToast because we will simply display a message instead of sending the rating to
the backend to keep the example simple. The event handler onRatingChange reads the value of our custom change event that is fired when the rating has
been submitted. We then display a confirmation message with the value in a MessageToast control.
webapp/css/style.css
.myAppDemoWTmyCustomButton.sapMBtn {
margin-right: 0.125rem;
}
.myAppDemoWTmyCustomText {
font-weight: bold;
}
/* ProductRating */
.myAppDemoWTProductRating {
padding: 0.75rem;
}
.myAppDemoWTProductRating .sapMRI {
vertical-align: initial;
}
To layout our control, we add a little padding to the root class to have some space around the three inner controls, and we override the alignment of the
RatingIndicator control so that it is aligned in one line with the label and the button.
We could also do this with more HTML in the renderer but this is the simplest way and it will only be applied inside our custom control. However, please be
aware that the custom control is in your app and might have to be adjusted when the inner controls change in future versions of SAPUI5.

# Detail Page
ratingConfirmation=You have rated this product with {0} stars
# Product Rating
productRatingLabelInitial=Please rate this product
productRatingLabelIndicator=Your rating: {0} out of {1}
productRatingLabelFinal=Thank you!
productRatingButton=Rate
The resource bundle is extended with the confirmation message and the strings that we reference inside the custom control. We can now rate a product on the
detail page with our brand new control.
Conventions
Put custom controls in the control folder of your app.
Previous: Step 33: Routing Back and History
Next: Step 35: Responsiveness
Related Information
Developing SAPUI5 Controls
Defining the Control Metadata
1.3.2.35 Step 35: Responsiveness

In this step, we improve the responsiveness of our app. SAPUI5 applications can be run on phone, tablet, and desktop devices and we can configure the
application to make best use of the screen estate for each scenario. Fortunately, SAPUI5 controls like the sap.m.Table already deliver a lot of features that
we can use.
Preview

Figure 1: A responsive table is hiding some of the columns on small devices
Coding
<mvc:View
xmlns="sap.m"
<Table
id="invoiceList"
width="auto"
items="{
sorter : {
group : true
}
}">
<headerToolbar>
<Toolbar>
<ToolbarSpacer/>
</Toolbar>
</headerToolbar>
<columns>
<Column
hAlign="End"
minScreenWidth="Small"
demandPopin="true"
width="4em">
<Text text="{i18n>columnQuantity}"/>
</Column>
<Column>
<Text text="{i18n>columnName}"/>
</Column>
<Column
minScreenWidth="Small"
demandPopin="true">
<Text text="{i18n>columnStatus}"/>
</Column>
<Column
minScreenWidth="Tablet"
demandPopin="false">
<Text text="{i18n>columnSupplier}"/>

</Column>
<Column
hAlign="End">
<Text text="{i18n>columnPrice}"/>
</Column>
</columns>
<items>
<ColumnListItem
type="Navigation"
press="onPress">
<cells>
<ObjectNumber number="{invoice>Quantity}" emphasized="false"/>
<ObjectIdentifier title="{invoice>ProductName}"/>
<Text text="{
}"/>
<Text text="{invoice>ShipperName}"/>
<ObjectNumber
number="{
formatOptions: {
showMeasure: false
}
}"
unit="{view>/currency}"
state="{= ${invoice>ExtendedPrice} > 50 ? 'Error' : 'Success' }"/>
</cells>
</ColumnListItem>
</items>
</Table>
</mvc:View>
We exchange the list with a table simply by replacing the tag <List> with <Table>. The table has a built-in responsiveness feature that allows us to make
the app more flexible. The table and the list share the same set of properties so we can simply reuse these and also the sorter.
Since a table has multiple cells in each row, we have to define columns for our table and name these according to the data. We add five sap.m.Column
controls to the column aggregation and configure each one a bit differently:
Quantity
This column will contain a short number, so we set the alignment to End (which means "right" in LTR languages) and the width to 4em which is long
enough for the column description. As a description text we use a sap.m.Text control that references a property of the resource bundle. We set the
property minScreenWidth to Small to indicate that this column is not so important on phones. We will tell the table to display this column below the
main column by setting the property demandPopin to true.
Name
Our main column that has a pretty large width to show all the details. It will always be displayed.
Status
The status is not so important, so we also display it below the name field on small screens by setting minScreenWidth to small and demandPopin
to true
Supplier
We completely hide the Supplier column on tablet and phone devices by setting minScreenWidth to Tablet and demandPopin to false.
Price
This column is always visible as it contains our invoice price.
Instead of the ObjectListItem that we had before, we will now split the information onto the cells that match the columns defined above. Therefore we
change it to a ColumnListem control with the same attributes, but now with cells aggregation. Here we create five controls to display our data:
Quantity
A simple sap.m.ObjectNumber control that is bound to our data field.
Name
A sap.m.ObjectIdentifier controls that specifies the name.
Status
A sap.m.Text control with the same formatter as before.
Supplier
A simple sap.m.Text control.
Price
An ObjectNumber control with the same formatter as the attributes number and numberUnit from the previous steps.
Now we have defined our table responsively and can see the results when we decrease the browsers screen size. The Supplier column is not shown on tablet
sizes and the two columns Quantity and Status will be shown below the name.
# App Descriptor
# Hello Panel
helloMsg=Hello {0}

# Invoice List
invoiceStatusA=New
invoiceStatusC=Done
columnQuantity=Quantity
columnName=Name
columnSupplier=Supplier
columnStatus=Status
columnPrice=Price
# Detail Page
# Product Rating
productRatingLabelInitial=Please rate this product
productRatingLabelIndicator=Your rating: {0} out of {1}
productRatingLabelFinal=Thank you!
productRatingButton=Rate
We add the column names and the attribute titles to our i18n file.
We can see the results when we decrease the browser's screen size or open the app on a small device.
Conventions
Optimize your application for the different screen sizes of phone, tablet, and desktop devices.
Previous: Step 34: Custom Controls
Next: Step 36: Device Adaptation
Related Information
Configuring Responsive Behavior of a Table
1.3.2.36 Step 36: Device Adaptation

We now configure the visibility and properties of controls based on the device that we run the application on. By making use of the sap.ui.Device API and
defining a device model we will make the app look great on many devices.
Preview

Figure 1: On phone devices, the panel is collapsed to save screen space and a button is hidden
Coding
<mvc:View
xmlns="sap.m"
<Panel
width="auto"
expandable="{device>/system/phone}"
expanded="{= !${device>/system/phone} }">
<content>
<Button
icon="sap-icon://world"
class="sapUiSmallMarginEnd sapUiVisibleOnlyOnDesktop"/>
<Button
press="onShowHello"
class="myAppDemoWTmyCustomButton"/>
<Input
width="60%"/>
<Text
class="sapUiSmallMargin sapThemeHighlight-asColor myAppDemoWTmyCustomText"/>
</content>
</Panel>
</mvc:View>
We add two new properties expandable and expanded to the HelloPanel. The user can now close and open the panel to have more space for the table
below on devices with small screens. The property expandable is bound to a model named device and the path /system/phone. So the panel can be
expanded on phone devices only. The device model is filled with the sap.ui.Device API of SAPUI5 as we see further down. The expanded property
controls the state of the panel and we use expression binding syntax to close it on phone devices and have the panel expanded on all other devices. The
device API of SAPUI5 offers more functionality to detect various device-specific settings, please have a look at the documentation for more details.

Note
The sap.ui.Device API detects the device type (Phone, Tablet, Desktop) based on the user agent and many other properties of the device. Therefore
simply reducing the screen size will not change the device type. To test this feature, you will have to enable device emulation in your browser or open it on
a real device.
We can also hide single controls by device type when we set a CSS class like sapUiVisibleOnlyOnDesktop or sapUiHideOnDesktop . We only show
the button that opens the dialog on desktop devices and hide it for other devices. For more options, see the documentation linked below.
webapp/Component.js
sap.ui.define([
"sap/ui/demo/wt/controller/HelloDialog",
"sap/ui/Device"
], function (UIComponent, JSONModel, HelloDialog, Device) {
"use strict";
metadata: {
manifest: "json"
},
init: function () {
// set data model

var oData = {
recipient: {
name: "World"
}
};
// disable batch grouping for v2 API of the northwind service
this.getModel("invoice").setUseBatch(false);
// set device model
var oDeviceModel = new JSONModel(Device);
oDeviceModel.setDefaultBindingMode("OneWay");
this.setModel(oDeviceModel, "device");
// set dialog
}
});
});
In the app component we add a dependency to sap.ui.Device and initialize the device model in the init method. We can simply pass the loaded
dependency Device to the constructor function of the JSONModel. This will make most properties of the SAPUI5 device API available as a JSON model.
The model is then set on the component as a named model so that we can reference it in data binding as we have seen in the view above.
Note
We have to set the binding mode to OneWay as the device model is read-only and we want to avoid changing the model accidentally when we bind
properties of a control to it. By default, models in SAPUI5 are bidirectional (TwoWay). When the property changes, the bound model value is updated as
well.
Tip
You can test the device specific features of your app with the developer tools of your browser. For example in Google Chrome, you can emulate a tablet or
a phone easily and see the effects. Some responsive options of SAPUI5 are only set initially when loading the app, so you might have to reload your page
to see the results.
<mvc:View
xmlns="sap.m"
xmlns:wt="sap.ui.demo.wt.control">
<Page
<ObjectHeader
responsive="true"

fullScreenOptimized="true"
number="{
formatOptions: {
showMeasure: false
}
}"
title="{invoice>ProductName}">
<attributes>
<ObjectAttribute title="{i18n>quantityTitle}" text="{invoice>Quantity}"></ObjectAttribute>
<ObjectAttribute title="{i18n>dateTitle}" text="{
path: 'invoice>ShippedDate',
type: 'sap.ui.model.type.Date',
formatOptions: {
style: 'long',
source: {
pattern: 'yyyy-MM-ddTHH:mm:ss'
}
}
}"/>
</attributes>
</ObjectHeader>
<wt:ProductRating class="sapUiSmallMarginBeginEnd" change="onRatingChange"/>
</Page>
</mvc:View>
Some controls already have built-in responsive features that can be configured. The ObjectHeader control can be put in a more flexible mode by setting the
attribute responsive to true and fullScreenOptimized to true as well. This will show the data that we add to the view now at different positions on the
screen based on the device size.
We add the number and numberUnit field from the list of the previous steps also to the ObjectHeader and use the same formatter with the currency
type as in the previous steps. We then define two attributes: The quantity of the invoice and the shipped date which is part of the data model. We have not
used this shippedDate field from the invoices JSON file so far, it contains a date in typical string format.
We now use the Date type and provide the pattern of our date format in the source section of the format options. It will display a more human-readable
formatted date text that also fits to small screen devices.
sap.ui.define([
"sap/ui/core/routing/History",
], function (Controller, History, MessageToast, JSONModel) {
use strict;
return Controller.extend(sap.ui.demo.wt.controller.Detail, {
currency: "EUR"
});

},
_onObjectMatched :
});
In the Detail controller we simply add the view model with our currency definition to display the number properly. It is the same code as in the
InvoiceList controller file.
# Detail Page
dateTitle=Order date
quantityTitle=Quantity
We add the column names and the attribute titles to our i18n file.
We can see the results when we decrease the browser's screen size or open the app on a small device.
Conventions
Optimize your application for the different screen sizes of phone, tablet, and desktop devices.

Previous: Step 35: Responsiveness
Next: Step 37: Content Density
1.3.2.37 Step 37: Content Density

In the last step of our Walkthrough tutorial, we adjust the content density based on the users device. SAPUI5 contains different content densities allowing you
to display larger controls for touch-enabled devices and a smaller, more compact design for devices that are operated by mouse. In our app, we will detect the
device and adjust the density accordingly.
Preview
Figure 1: The content density is compact on desktop devices and cozy on touch-enabled devices
Coding
webapp/Component.js
...
init: function ()
},
getContentDensityClass : function() {
if (!this._sContentDensityClass) {
if (!sap.ui.Device.support.touch) {
this._sContentDensityClass = "sapUiSizeCompact";
} else {
this._sContentDensityClass = "sapUiSizeCozy";
}
}
return this._sContentDensityClass;
}
});
});
To prepare the content density feature we will also add a helper method getContentDensityClass. SAPUI5 controls can be displayed in multiple sizes,
for example in a compact size that is optimized for desktop and non-touch devices, and in a cozy mode that is optimized for touch interaction. The controls
look for a specific CSS class in the HTML structure of the application to adjust their size.
This helper method queries the sap.ui.Device API directly for touch support of the client and returns the CSS class sapUiSizeCompact if touch
interaction is not supported and sapUiSizeCozy for all other cases. We will use it throughout the application coding to set the proper content density CSS
class.
sap.ui.define([
"use strict";
this.getView().addStyleClass(this.getOwnerComponent().getContentDensityClass());

},
onOpenDialog: function () {
}
});
});
We add a method onInit on the app controller that is called when the app view is instantiated. There we query the helper function that we defined on the app
component to set the corresponding style class on the app view, All controls inside the app view will now automatically adjust either to the compact or cozy
size as defined by the style.
webapp/controller/HelloDialog.js
sap.ui.define([
"sap/ui/base/Object"
], function (Object) {
"use strict";
return Object.extend("sap.ui.demo.wt.controller.HelloDialog", {
_getDialog: function () {
}
},
open: function (oView) {
var oDialog = this._getDialog();
// forward compact/cozy style into Dialog
jQuery.sap.syncStyleClass(oView.getController().getOwnerComponent().getContentDensityClass(), oView, oDialog);

oView.addDependent(oDialog);
// open dialog
oDialog.open();
},
onCloseDialog: function () {
}
});
});
The "Hello World" dialog is not part of the app view but opened in a special part of the DOM called "static area". The content density class defined on the app
view is not known to the dialog so we sync the style class of the app with the dialog manually.
This was the last step, you have successfully completed the Walkthrough!
Previous: Step 36: Device Adaptation
Next: Summary
Related Information
Content Densities
1.3.4.18 Summary
You should now be familiar with the major development paradigms and concepts of SAPUI5 and have created a very simple first app. You are now ready to
build a proper app based on what you've learned.
If you want to dive deeper into specific topics, you can use the other tutorials that show some of the aspects of this walkthrough and advanced topics in more
detail.
Previous: Step 37: Content Density
1.3.3 Data Binding

In this tutorial, we will explain the concepts of data binding in SAPUI5.
SAPUI5 uses data binding to bind two data sources or information sources together to keep them in sync: All changes in one source are also reflected in the
other one.
For data binding, you need a model and a binding instance: The model instance holds the data and provides methods to set the data or to retrieve the data
from a server. It also provides a method for creating bindings to the data. When this method is called, a binding instance is created, which contains the binding
information and provides an event, which is fired whenever the bound data changes. An element can listen to this event and update its visualization according
to the new data.

The UI uses data binding to bind controls to the model which holds the application data, so that the controls are updated automatically whenever application
data changes. Data binding is also used the other way round, when changes in the control cause updates in the underlying application data, for example data
entered by the user. This is called two-way binding.
Preview
Tip
You can view and download the files for all steps in the Explored app in the demo kit under Data Binding . Depending on your development environment
you might have to adjust resource paths and configuration entries.
Prerequisites
Troubleshooting
1. Step 1: No Data Binding

In this step, we simply place some text on the screen using a standard sap.m.Text control. The text in this control is a hard-coded part of the control's
definition; therefore, this is not an example of data binding!
2. Step 2: Creating a Model
In this step, we create a model as container for the data on which your application operates.
3. Step 3: Create Property Binding
Although there is no visible difference, the text on the screen is now derived from model data.
4. Step 4: Two-Way Data Binding
In the examples used so far, we have used a read-only field to display the value of a model property. We will now change the user interface so that the
first and last name fields are displayed using sap.m.Input fields and an additional check box control is used to enable or disable both input fields.
This arrangement illustrates a feature known as "two-way data binding". Now that the view contains more controls, we will also move the view definition
into an XML file.
5. Step 5: One-Way Data Binding
In contrast to the two-way binding behavior shown above, one-way data binding is also possible. Here, data is transported in one direction only: from the
model, through the binding instance to the consumer (usually the property of a control), but never in the other direction. In this example, we will change
the previous example to use one-way data binding. This will illustrate how the flow of data from the user interface back to the model can be switched off
if required.
6. Step 6: Resource Models
Business applications also require language-specific (translatable) texts used as labels and descriptions on the user interface.
7. Step 7: (Optional) Resource Bundles and Multiple Languages
The reason we have resource bundles is to allow an app to run in multiple languages without the need to change any code. To demonstrate this feature,

we will create a German version of the app in fact all we need to do is create a German version of the resource bundle file. No code changes are
needed.
8. Step 8: Binding Paths: Accessing Properties in Hierarchically Structured Models
In step 6 , we stated that the fields in a resource model are arranged in a flat structure; in other words, there can be no hierarchy of properties; however,
this is true only for resource models. The properties within JSON and OData models almost always are arranged in a hierarchical structure. Therefore,
we should take a look at how to reference fields in a hierarchically structured model object.
9. Step 9: Formatting Values
We also want to provide our users a way of contacting Harry Hawk. Therefore we will add a link that sends an e-mail to Harry. To achieve that we will
convert our data in the model to match the sap.m.URLHelper.normalizeEmail API. As soon as the user changes the name, the e-mail will also
change. We will need a custom formatter function for this.
10. Step 10: Property Formatting Using Data Types
SAPUI5 provides a set of simple data types such as Boolean, Currency, Date and Float. These data types can then be applied to controls in order
to ensure that the value presented on the screen is formatted correctly, and, if the field is open for input, that the value entered by the user adheres to
the requirements of that data type. We will now add a new field called Sales to Date of type Currency.
11. Step 11: Validation Using the Message Manager
So far, we have created a currency field that can format itself correctly. The currency data type also has the ability to validate that user input adheres to
to the requirements of a currency; however, data type validation functions are managed by SAPUI5, which of itself has no mechanism for reporting error
messages back to the UI; therefore, we need a mechanism for reporting error messages raised by validation functions back to the user. In this step, we
will connect the entire view to a feature known as the "Message Manager". Once this connection is established, any validation error messages
generated based on the user input will be passed to the message manager which in turn will connect them to the appropriate view and control that
caused the error.
12. Step 12: Aggregation Binding Using Templates
Aggregation binding allows a control to be bound to a list within the model data and allows relative binding to the list entries by its child controls.
13. Step 13: Element Binding
Now we want to do something with that newly generated list. In most cases you will use a list to allow the selection of an item and then show the details
of that item elsewhere. In order to achieve this, we use a form with relatively bound controls an bind it to the selected entity via element binding.
14. Step 14: Expression Binding
Expression binding allows you to display a value on the screen that has been calculated from values found in some model object. This way simple
formatting or calculations can be inserted directly into the data binding string. In this example, we will change the color of the price depending on whether
it is above or below some arbitrary threshold. The threshold value is also stored in the JSON model.
15. Step 15: Aggregation Binding Using a Factory Function
Instead of hard-coding a single template control, we will use a factory function to generate different controls based on the data received at runtime. This
approach is much more flexible and allows complex or heterogeneous data to be displayed.
Related Information
Data Binding
1.3.3.1 Step 1: No Data Binding

In this step, we simply place some text on the screen using a standard sap.m.Text control. The text in this control is a hard-coded part of the control's
definition; therefore, this is not an example of data binding!
Preview
Figure 1: Screen with text
Coding
You can view and download all files in the Explored app in the Demo Kit under Data Binding - Step 1 .
webapp/index.html (New)
<!DOCTYPE html>
<html>
<head>
<title>Data Binding Tutorial</title>
<script
src="../resources/sap-ui-core.js"
>

</script>
<script>
// Attach an anonymous function to the 'init' event
// Create a text UI element that displays a hardcoded text string
new sap.m.Text({text: "Hi, my name is Harry Hawk"}).
placeAt("content");
});
</script>
</body>
</html>
Create a new folder webapp which will contain all sources of the app we will create throughout this tutorial, and create the index.html file within this folder
Since the value of text property of the sap.m.Text control has been hard-coded, it is unrelated to any data that might exist within a model object. Therefore,
data binding is not being used here.
Parent topic: Data Binding
Next: Step 2: Creating a Model
1.3.3.2 Step 2: Creating a Model

In this step, we create a model as container for the data on which your application operates.
The business data within a model can be defined using various formats:
JavaScript Object Notation (JSON)
Extensible Markup Language (XML)
OData
Your own custom format (not covered in this tutorial)
Note
There is also a special type of model called a "resource model". This model type is used as a wrapper object around a resource bundle file. The names of
such files must end with .properties and are used typically for holding language-specific text.
We will use this in Step 6: Resource Models.
When JSON, XML and resource models are created, the data they contain is loaded in a single request (either from a file stored locally on the client or by
requesting it from a Web server). In other words, after the model's data has been requested, the entire model is known to the application. These models are
known as client-side models and tasks such as filtering and sorting are performed locally on the client.
An OData model however, is a server-side model. This means that whenever an application needs data from the model, it must be requested from the server.
Such a request will almost never return all the data in the model, typically because this would be far more data than is required by the client application.
Consequently, tasks such as sorting and filtering should always be delegated to the server.
In this tutorial, we will focus on JSON models since they are the simplest ones to work with.
Preview
Figure 1: Screen with text derived from a model object (No visual changes to last step)
Coding
webapp/index.html
...
<script>
// Attach an anonymous function to the SAPUI5 'init' event
// Create a JSON model from an object literal
var oModel = new sap.ui.model.json.JSONModel({
greetingText: "Hi, my name is Harry Hawk"
});
// Assign the model object to the SAPUI5 core
sap.ui.getCore().setModel(oModel);
// Create a text UI element that displays a hardcoded text string

new sap.m.Text({text: "{/greetingText}"})

.placeAt("content");
});
</script>
...
Create a new JSON model passing the data as object literal and store the resulting model instance in a local variable called oModel.
Set oModel to be the default model within the entire SAPUI5 core.
This makes the model object globally available to all controls used within the application.
In this case we have bound the model object to the SAPUI5 core. This has been done for simplicity, but is not considered good practice. Generally speaking,
a model object holding business data should be bound to the view that displays the data. We will correct this part of the code in the following steps.
Note
Models can be set on every control by calling setModel(). The model is then propagated to all aggregated child controls (and their children, and so
on). All child control will then have access to that model
The text that is displayed on the UI is still not taken from the model - we will do this in the next step.
Previous: Step 1: No Data Binding
Next: Step 3: Create Property Binding
Related Information
Models
JSON Model
1.3.3.3 Step 3: Create Property Binding

Although there is no visible difference, the text on the screen is now derived from model data.
Preview
Figure 1: Screen with text derived from various sources (No visual changes to last step)
Coding
webapp/index.html
...
<script>
greetingText: "Hi, my name is Harry Hawk"
});

// Display a text element whose text is derived
// from the model object
new sap.m.Text({ text : "{/greetingText}" }).
placeAt("content");
});
</script>
...
The text property of the sap.m.Text control is set to the value {/greetingText}. The curly brackets enclosing a binding path (binding syntax) are
automatically interpreted as a binding. These binding instances are called PropertyBindings. In this case, the control's text property is bound to the
greetingText property at the root of the default model, as the slash (/) at the beginning of the binding path denotes an absolute binding path.

Previous: Step 2: Creating a Model
Next: Step 4: Two-Way Data Binding
Related Information
Binding Controls to the Model
Property Binding
1.3.3.4 Step 4: Two-Way Data Binding

In the examples used so far, we have used a read-only field to display the value of a model property. We will now change the user interface so that the first
and last name fields are displayed using sap.m.Input fields and an additional check box control is used to enable or disable both input fields. This
arrangement illustrates a feature known as "two-way data binding". Now that the view contains more controls, we will also move the view definition into an XML
file.
Preview
Figure 1: Input fields can be enabled or disabled
Coding
webapp/view/App.view.xml (New)
<mvc:View xmlns="sap.m" xmlns:mvc="sap.ui.core.mvc">
<Panel headerText="{/panelHeaderText}" class="sapUiResponsiveMargin" width="auto">
<content>
<Label text="First Name" class="sapUiSmallMargin" />
<Input value="{/firstName}" valueLiveUpdate="true" width="200px" enabled="{/enabled}" />
<Label text="Last Name" class="sapUiSmallMargin" />
<Input value="{/lastName}" valueLiveUpdate="true" width="200px" enabled="{/enabled}" />
<CheckBox selected="{/enabled}" text="Enabled" />
</content>
</Panel>
</mvc:View>
We create a new view folder in our app and a new file for our XML view inside the app folder.
webapp/index.html
<!DOCTYPE html>
<html>
<head>
<title>SAPUI5 Data Binding Tutorial</title>
<script
src="../../../../../../../../../resources/sap-ui-core.js"
data-sap-ui-resourceroots='{ "sap.ui.demo.db": "./" }'
>
</script>
<script>
firstName: "Harry",
lastName: "Hawk",
enabled: true,
panelHeaderText: "Data Binding Basics"
});

// Display the XML view called "App"
new sap.ui.core.mvc.XMLView({ viewName : "sap.ui.demo.db.view.App" })
});
</script>
</head>
</body>
</html>
We add the parameter data-sap-ui-resourcerouts to the bootstrap.

We delete the code that assigned the sap.m.Text field to the UI and add an XML view that is identified by its resource name.
You can now refresh the application preview and select or deselect the checkbox. You will see that the input fields are automatically enabled or disabled in
response to the state of the checkbox.
It is clear that we have not written any code to transfer data between the user interface and the model, yet the Input controls are enabled or disabled
according to the state of the checkbox. This behaviour is the result of the fact that all SAPUI5 models implement two-way data binding, and for JSON Models,
two-way binding is the default behavior.
Two things are happening here:
Data binding allows the property of a control to derive its value from any suitable property in a model.
SAPUI5 automatically handles the transport of data both from the model to the controls, and back from the controls to the model. This is called two-way
binding.
Previous: Step 3: Create Property Binding
Next: Step 5: One-Way Data Binding
Related Information
Data Binding
1.3.3.5 Step 5: One-Way Data Binding

In contrast to the two-way binding behavior shown above, one-way data binding is also possible. Here, data is transported in one direction only: from the
model, through the binding instance to the consumer (usually the property of a control), but never in the other direction. In this example, we will change the
previous example to use one-way data binding. This will illustrate how the flow of data from the user interface back to the model can be switched off if
required.
Preview
Figure 1: Two-way data binding disabled for the checkbox
Coding
webapp/index.html
...
<script>
firstName : "Harry",
lastName : "Hawk",
enabled : true,

panelHeaderText : "Data Binding Basics"
});
oModel.setDefaultBindingMode(sap.ui.model.BindingMode.OneWay);
...
Insert the single highlighted line immediately after the creation of the model object in index.html.
Now, no matter what state the checkbox is in, the input fields remain open for input because one-way data binding ensures that data flows only from the model
to the UI, but never in the other direction.
The binding mode (one-way or two-way) is set on the model itself. Therefore, unless you specifically alter it, a binding instance will always be created using the
model's default binding mode.
Should you wish to alter the binding mode, then there are two ways of doing this:
Alter the model's default binding mode. This is the approach used above.
Specify the data binding mode for a specific binding instance by using the oBindingInfo.mode parameter. This change applies only to this data
binding instance. Any other binding instances will continue to use the model's default binding mode. For more information, see the API Reference for
sap.ui.base.ManagedObject.bindProperty in the Demo Kit.
Note
There are two important points to understand about alterations to a model object's data binding mode:
If you alter the default binding mode of a model (as in the example above), then unless you explicitly say otherwise, all binding instances created
after that point in time will use the altered binding mode.
Altering a model's default binding mode has no effect on already existing binding instances.
Previous: Step 4: Two-Way Data Binding
Next: Step 6: Resource Models
1.3.3.6 Step 6: Resource Models

Business applications also require language-specific (translatable) texts used as labels and descriptions on the user interface.
The example we used at the start of this tutorial was overly simplistic as we stored language-specific text directly in a JSON model object. Generally
speaking, unless language-specific text is derived directly from a back-end system, it is not considered good programming practice to place translatable texts
directly into a model. So let's correct this situation by placing all translatable texts (such as field labels) into a resource bundle.
Preview
Figure 1: Texts derived from the resource model (No visual change to last step)
Coding
webapp/index.html
...
<script>
lastName : "Hawk",
enabled : true
});
// Create a resource bundle for language specific texts

var oResourceModel = new sap.ui.model.resource.ResourceModel({
bundleName : "sap.ui.demo.db.i18n.i18n"
});
// Assign the model object to the SAPUI5 core using the name "i18n"
sap.ui.getCore().setModel(oResourceModel, "i18n");
// Display the XML view called "App"

new sap.ui.core.mvc.XMLView({ viewName : "sap.ui.demo.db.views.App" })

</script>
...
Since we are creating a resource model, the file name is assumed to have the extension .properties; this does not need to be stated explicitly. The
resource model is set to the core using the model name i18n.
Note
Remove , panelHeaderText : "Data Binding Basics" from the model definition in the index.html file. This text is now moved to the
resource model.
webapp/i18n/i18n.properties (New)
# Field labels
firstName=First Name
lastName=Last Name
enabled=Enabled
# Screen titles
panelHeaderText=Data Binding Basics
Create a new folder i18n, and a new file i18n.properties within and add the code above.
The panelHeaderText property has been moved from the JSON model into the i18n resource bundle, also the field labels are no longer hard coded in the
XML view. This is because all of these text fields need to be translated.
Language-specific text stored in resource models obeys the Java convention for internationalization (i18n).
<Panel headerText="{i18n>panelHeaderText}" class="sapUiResponsiveMargin" width="auto">
<content>
<Label text="{i18n>firstName}" class="sapUiSmallMargin" />
<Label text="{i18n>lastName}" class="sapUiSmallMargin" />
<CheckBox selected="{/enabled}" text="{i18n>enabled}" />
</content>
</Panel>
</mvc:View>
Modify the data binding for the panel header and the labels in App.view.xml to include the model name. Notice that a "greater than" character separates the
model name and the property name, and that i18n property names must not to start with a slash character!
You could use multiple model instances by using different model names. The model name could be set as second parameter using the
setModel(oResourceModel,i18n) method. The model is then propagated under this name to all aggregated child controls (and their children, and so
on). All these controls have access to this model under the name i18n as well as to the JSONModel (default model, which has no name).
Previous: Step 5: One-Way Data Binding
Next: Step 7: (Optional) Resource Bundles and Multiple Languages
Related Information
Resource Model
1.3.3.7 Step 7: (Optional) Resource Bundles and Multiple

Languages
The reason we have resource bundles is to allow an app to run in multiple languages without the need to change any code. To demonstrate this feature, we will
create a German version of the app in fact all we need to do is create a German version of the resource bundle file. No code changes are needed.
Preview
Figure 1: German version of our UI

Coding
webapp/i18n/i18n_de.properties (New)
# Field labels
firstName=Vorname
lastName=Nachname
enabled=Aktiviert
# Screen titles
panelHeaderText=Data Binding Grundlagen
In the i18n folder, take a copy of the file i18n.properties and call it i18n_de.properties. Change the English text to the German text.
To test the outcome, change the default language of your browser to German and refresh your preview.
Previous: Step 6: Resource Models
Next: Step 8: Binding Paths: Accessing Properties in Hierarchically Structured Models
Related Information
Localization
1.3.3.8 Step 8: Binding Paths: Accessing Properties in

Hierarchically Structured Models
In step 6 , we stated that the fields in a resource model are arranged in a flat structure; in other words, there can be no hierarchy of properties; however, this is
true only for resource models. The properties within JSON and OData models almost always are arranged in a hierarchical structure. Therefore, we should take
a look at how to reference fields in a hierarchically structured model object.
Preview
Figure 1: Second panel with additional data
Coding
webapp/index.html
...
<script>
// ------------------------------------------------------------------------
// Attach an anonymous function to the 'init' event
lastName : "Hawk",
enabled : true,
address : {
street : "Dietmar-Hopp-Allee 16",
city : "Walldorf",
zip : "69190",
country : "Germany"
}

});
...
The JSON model object now contains an additional sub-object called address. Within this object are four properties: street, city, zip, and country.
<mvc:View xmlns="sap.m" xmlns:l="sap.ui.layout" xmlns:mvc="sap.ui.core.mvc">
<Panel headerText="{i18n>panel1HeaderText}" class="sapUiResponsiveMargin" width="auto">
<content>
</content>
</Panel>
<content>
<l:VerticalLayout>
<Label class="sapUiSmallMargin" text="{i18n>address}:" />
<Text class="sapUiSmallMargin"
text="{/address/street}\n{/address/zip} {/address/city}\n{/address/country}"
width="200px" />
</l:VerticalLayout>
</content>
</Panel>
</mvc:View>
We add a new panel to the XML view with a new Label and Text pair of elements.
The text property of the Label element is bound to the i18n resource bundle field address.
The text property of the Text element is bound to three i18n properties: /address/street, /address/zip, /address/city, and
/address/country. The resulting address format is achieved by separating each one of these model property references with a hard-coded newline
character while zip and city are separated by a space.
# Field labels
firstName=First Name
lastName=Last Name
enabled=Enabled
address=Address
# Screen titles
panel1HeaderText=Data Binding Basics
panel2HeaderText=Address Details
webapp/i18n/i18n_de.properties
# Field labels
firstName=Vorname
lastName=Nachname
enabled=Aktiviert
address=Adresse
# Screen titles
panel1HeaderText=Data Binding Grundlagen
panel2HeaderText=Adressdetails
Note
The resource bundle files now contain new properties for the Address and a new panel header text. Both panel properties have been numbered.
In the XML view, inside the curly brackets for the binding path of the Text element, notice that the first character is a forward slash. This is required for
binding paths that make absolute references to properties in JSON and OData models, but must not be used for resource models. After the first forward
slash character, the binding path syntax uses the object names and the property name separated by forward slash characters ({/address/street}).
As has been mentioned previously, all binding path names are case-sensitive.
Previous: Step 7: (Optional) Resource Bundles and Multiple Languages
Next: Step 9: Formatting Values

Related Information
JSON Model
1.3.3.9 Step 9: Formatting Values

We also want to provide our users a way of contacting Harry Hawk. Therefore we will add a link that sends an e-mail to Harry. To achieve that we will convert
our data in the model to match the sap.m.URLHelper.normalizeEmail API. As soon as the user changes the name, the e-mail will also change. We
will need a custom formatter function for this.
Preview
Figure 1: Address with e-mail link
Coding
webapp/controller/App.controller.js (New)
sap.ui.define(["sap/ui/core/mvc/Controller"],
function (Controller) {
"use strict";
formatMail: function(sFirstName, sLastName) {
return sap.m.URLHelper.normalizeEmail(
sFirstName + "." + sLastName + "@example.com",
oBundle.getText("mailSubject", [sFirstName]),
oBundle.getText("mailBody"));
}
});
});
Create a new folder controller within your webapp folder as a general location for all controller files for this app and create a new file
App.controller.js.
In our custom formatter, we define the first and last name that are currently in the model as function parameters. When a user changes the data in the model
by entering a different name in the input fields, our formatter will be invoked automatically by the framework. This makes sure that the UI is in sync with the
data model.
In the formatter function, we use the sap.m.URLHelper.normalizeEmail function that expects an e-mail address, a mail subject and a text body.
When a user chooses the link, the default email client will open with these parameters. The mailSubject resource bundle text will contain a placeholder for
the first name of the recipient (see below). Therefore, we provide the name with [sFirstName].
Note
For a detailed description of the e-mail link format, see https://developer.mozilla.org/de/docs/Web/Guide/HTML/Email_links .
<mvc:View xmlns="sap.m" xmlns:l="sap.ui.layout"
controllerName="sap.ui.demo.db.controller.App">
<content>
</content>
</Panel>

<content>
<l:VerticalLayout>
<Text class="sapUiSmallMarginBegin sapUiSmallMarginBottom" text="{/address/street}\n{/address/zip} {/address/city}\n{/addr
<Link class="sapUiSmallMarginBegin"
href="{
parts: [
'/firstName',
'/lastName'
],
formatter: '.formatMail'
}"
text="{i18n>sendEmail}"/>
</l:VerticalLayout>
</content>
</Panel>
</mvc:View>
For more complex bindings we cannot use the simple binding syntax with the curly braces anymore. The href property of the Link element now contains an
entire object inside the string value. In this case, the object has two properties:
parts
This is a JavaScript array in which each element is an object containing a path property. The number and order of the elements in this array
corresponds directly to the number and order of parameters expected by the formatMail function.
formatter
A reference to the function that receives the parameters listed in the parts array. Whatever value is returned by the formatter function becomes the
value set for this property. The dot ( formatMail) at the beginning of the formatter tellsSAPUI5 to look for a formatMail function on the controller
instance of the view. If you do not use the dot, the function will be resolved by looking into the global namespace.
Note
When using formatter functions, the binding is automatically switched to "one-way". So you cant use a formatter function for "two-way" scenarios, but you
can use data types (which will be explained in the following steps).

# Screen titles
panel2HeaderText=Adress Details
# E-mail
sendEmail=Send Mail
mailSubject=Hi {0}!
mailBody=How are you?

# Screen titles
# E-mail
sendEmail=E-mail versenden
mailSubject=Hallo {0}!
mailBody=Wie geht es dir?
And we add the missing texts to the properties files
Previous: Step 8: Binding Paths: Accessing Properties in Hierarchically Structured Models
Next: Step 10: Property Formatting Using Data Types
Related Information
Custom Formatter Functions
1.3.3.10 Step 10: Property Formatting Using Data Types

SAPUI5 provides a set of simple data types such as Boolean, Currency, Date and Float. These data types can then be applied to controls in order to
ensure that the value presented on the screen is formatted correctly, and, if the field is open for input, that the value entered by the user adheres to the
requirements of that data type. We will now add a new field called Sales to Date of type Currency.
Preview

Preview
Figure 1: New Sales to Date input field
Coding
webapp/index.html
<script>
lastName : "Hawk",
enabled : true,
address : {
street : "Dietmar-Hopp-Allee 16",
city : "Walldorf",
zip : "69190",
country : "Germany"
},
"salesToDate" : 12345.6789,
"currencyCode" : "EUR"
});
...
We create two new model properties salesToDate and currencyCode.
...
<content>
<l:HorizontalLayout>
<l:VerticalLayout>
<Text class="sapUiSmallMarginBegin sapUiSmallMarginBottom" text="{/address/street}\n{/address/zip} {/address/city}\n{/address
<Link class="sapUiSmallMarginBegin"
href="{
parts: [
'/firstName',
'/lastName'
],
formatter: '.formatMail'
}"
text="{i18n>sendEmail}"/>
</l:VerticalLayout>
<l:VerticalLayout>
<Label text="{i18n>salesToDate}:" class="sapUiSmallMargin" />
<Input width="200px" enabled="{/enabled}" description="{/currencyCode}"
value="{ parts: [{path: '/salesToDate'}, {path: '/currencyCode'}], type: 'sap.ui.model.type.Currency', formatOptions: {sh
</l:VerticalLayout>
</l:HorizontalLayout>
</content>
</Panel>
</mvc:View>
A new pair of Label and Input elements have been created for the salesToDate model property. The description property of the Input element has been
bound to the currencyCode model property. The value property of the Input element has been bound to the model properties salesToDate and
currencyCode. The {showMeasure: false} parameter switches off the display of the currency symbol within the input field itself. This is not needed
because it is being displayed using the Input element's description property.

# Field labels
firstName=Vorname
lastName=Nachname
enabled=Enabled
address=Address
salesToDate=Sales to Date...
# Field labels
firstName=Vorname
lastName=Nachname
enabled=Aktiviert
address=Adresse
salesToDate=Verkufe bis zum heutigen Datum
...
Add the missing texts to the properties files.
Previous: Step 9: Formatting Values
Next: Step 11: Validation Using the Message Manager
Related Information
Using the Data Binding Type System
1.3.3.11 Step 11: Validation Using the Message Manager

So far, we have created a currency field that can format itself correctly. The currency data type also has the ability to validate that user input adheres to to the
requirements of a currency; however, data type validation functions are managed by SAPUI5, which of itself has no mechanism for reporting error messages
back to the UI; therefore, we need a mechanism for reporting error messages raised by validation functions back to the user. In this step, we will connect the
entire view to a feature known as the "Message Manager". Once this connection is established, any validation error messages generated based on the user
input will be passed to the message manager which in turn will connect them to the appropriate view and control that caused the error.
Preview
Figure 1: A message appears
Coding
webapp/index.html
...
<script>
...
var oResourceBundle = new sap.ui.model.resource.ResourceModel({

bundleName: "sap.ui.demo.db.i18n.i18n"
});
sap.ui.getCore().setModel(oResourceBundle, "i18n");
// Create view

var oView = new sap.ui.core.mvc.XMLView({ viewName : "sap.ui.demo.db.view.App" });
// Register the view with the message manager

sap.ui.getCore().getMessageManager().registerObject(oView, true);
// Insert the view into the DOM

oView.placeAt("content");
});
</script>
</head>
</body>
</html>
The changes to the coding are minimal:
The XML view is now created as a named object called oView.
The view object oView is registered with the MessageManager.
Once registered, the XML view is then inserted into the DOM as before.
You can now enter a non-numeric value into the Sales To Date field and either press Enter or move the focus to a different UI control. This action triggers
either the onenter or onchange event and then SAPUI5 executes the validation function belonging to the sap.ui.model.type.Currency data type.
Now that the view has been registered with the MessageManager, any validation error messages will be picked up by the MessageManager, which in turn
checks its list of registered objects and then passes the error message back to the correct view for display.
Note that the field in error has a red border:
However, the error message itself will only be displayed when that particular field has focus:
Previous: Step 10: Property Formatting Using Data Types
Next: Step 12: Aggregation Binding Using Templates
Related Information
Managing UI and Server Messages
1.3.3.12 Step 12: Aggregation Binding Using Templates

Aggregation binding allows a control to be bound to a list within the model data and allows relative binding to the list entries by its child controls.
It will automatically create as many child controls as are needed to display the data in the model using one of the following two approaches:
Use template control that is cloned as many times as needed to display the data.
Use a factory function to generate the correct control per bound list entry based on the data received at runtime.
Preview

Figure 1: List with aggregation binding
Coding
webapp/index.html
...
<script>
var oProductModel = new sap.ui.model.json.JSONModel();
oProductModel.loadData("./model/Products.json");
sap.ui.getCore().setModel(oProductModel, "products");
firstName: "Harry",
lastName: "Hawk",
enabled: true,
address: {
street: "Dietmar-Hopp-Allee 16",
city: "Walldorf",
zip: "69190",
country: "Germany"
},
});
...
... <Input width="200px" enabled="{/enabled}" description="{/currencyCode}"
value="{ parts: [{path: '/salesToDate'}, {path: '/currencyCode'}], type: 'sap.ui.model.type.Currency', formatOptions: {showM
</l:VerticalLayout>
</content>
</Panel>
<content>
<List headerText="{i18n>productListTitle}" items="{products>/Products}">
<items>
<ObjectListItem title="{products>ProductName}"
number="{ parts:
[
{path: 'products>UnitPrice'},
{path: '/currencyCode'}
],
formatOptions: { showMeasure: false }

}"
numberUnit="{/currencyCode}">
<attributes>
<ObjectAttribute text="{products>QuantityPerUnit}"/>
<ObjectAttribute title="{i18n>stockValue}"
text="{ parts: [
{path: 'products>UnitPrice'},
{path: 'products>UnitsInStock'},
{path: '/currencyCode'}
],
formatter: '.formatStockValue'
}" />
</attributes>
</ObjectListItem>
</items>
</List>
</content>
</Panel>
</mvc:View>
We add a new panel to the view.
sap.ui.define(["sap/ui/core/mvc/Controller","sap/ui/model/type/Currency"],
function (Controller, Currency) {
"use strict";
return Controller.extend("sap.ui.demo.db.controller.App", {
},
formatStockValue: function(fUnitPrice, iStockLevel, sCurrCode) {
var sBrowserLocale = sap.ui.getCore().getConfiguration().getLanguage();
var oLocale = new sap.ui.core.Locale(sBrowserLocale);
var oLocaleData = new sap.ui.core.LocaleData(oLocale);
var oCurrency = new Currency(oLocaleData.mData.currencyFormat);
return oCurrency.formatValue([fUnitPrice * iStockLevel, sCurrCode], "string");
}
});
});
webapp/model/Products.json (New)
{ "Products": [ {
"ProductID": 1,
"ProductName": "Chai",
"SupplierID": 1,
"CategoryID": 1,
"QuantityPerUnit": "10 boxes x 20 bags",
"UnitPrice": "18.0000",
"UnitsInStock": 39,
"UnitsOnOrder": 0,
"ReorderLevel": 10,
"Discontinued": false
}, {
"ProductID": 2,
"ProductName": "Chang",
"SupplierID": 1,
"CategoryID": 1,
"QuantityPerUnit": "24 - 12 oz bottles",
"UnitPrice": "19.0000",
"UnitsInStock": 17,
"UnitsOnOrder": 40,
"ReorderLevel": 25,
"Discontinued": true
}, {
"ProductID": 3,
"ProductName": "Aniseed Syrup",
"SupplierID": 1,
"CategoryID": 2,

"QuantityPerUnit": "12 - 550 ml bottles",
"UnitPrice": "10.0000",
"UnitsInStock": 0,
"UnitsOnOrder": 70,
"ReorderLevel": 25,
}, {
"ProductID": 4,
"ProductName": "Chef Anton's Cajun Seasoning",
"SupplierID": 2,
"CategoryID": 2,
"QuantityPerUnit": "48 - 6 oz jars",
"UnitPrice": "22.0000",
"UnitsInStock": 53,
"UnitsOnOrder": 0,
"ReorderLevel": 0,
}, {
"ProductID": 5,
"ProductName": "Chef Anton's Gumbo Mix",
"SupplierID": 2,
"CategoryID": 2,
"QuantityPerUnit": "36 boxes",
"UnitPrice": "21.3500",
"UnitsInStock": 0,
"UnitsOnOrder": 0,
"ReorderLevel": 0,
"Discontinued": true
}]
}
We now use a new JSON model file for product data.
...
# Screen titles
panel3HeaderText=Aggregation Binding
# Invoice List
statusA=New
statusB=In Progress
statusC=Done
# Product list
productListTitle=Product List
stockValue=Current Stock Value
...
# Screen titles
# Invoice List
invoiceListTitle=Rechnungen
statusA=Neu
statusB=Laufend
statusC=Abgeschlossen
# Product list
productListTitle=Artikelliste
stockValue=Lagerbestand Wert
We add the missing texts.
Previous: Step 11: Validation Using the Message Manager
Next: Step 13: Element Binding

Related Information
Aggregation Binding
1.3.3.13 Step 13: Element Binding

Now we want to do something with that newly generated list. In most cases you will use a list to allow the selection of an item and then show the details of
that item elsewhere. In order to achieve this, we use a form with relatively bound controls an bind it to the selected entity via element binding.
Preview
Figure 1: Element binding implemented, product details displayed per item
Coding
...
</items>
</List>
</content>
</Panel>
<Panel id="productDetailsPanel" headerText="{i18n>panel4HeaderText}" class="sapUiResponsiveMargin" width="auto">
<l:Grid defaultSpan="L3 M6 S12" containerQuery="true">
<Label text="{i18n>ProductID}:" />
<Input value="{products>ProductID}" />
<Label text="{i18n>ProductName}:" />

<Input value="{products>ProductName}" />
<Label text="{i18n>QuantityPerUnit}:" />

<Input value="{products>QuantityPerUnit}" />
<Label text="{i18n>UnitPrice}:" />

<Input value="{products>UnitPrice}" />
<Label text="{i18n>UnitsInStock}:" />

<Input value="{products>UnitsInStock}" />
<Label text="{i18n>Discontinued}:" />

<CheckBox selected="{products>Discontinued}" />
</l:Grid>
</Panel>
</mvc:View>
Now we have an empty form. In order to fill this form with data, we will bind the whole panel to the path of the element which we clicked in the list. We need to
add a press-event handler to the items in the list.

webapp/view/App.views.xml
...
<content>
<List headerText="{i18n>productListTitle}" items="{products>/Products}">
<items>
<ObjectListItem
press=".onItemSelected"
type="Active"
title="{products>ProductName}"
number="{ parts: [{path: 'products>UnitPrice'},
{path: '/currencyCode'}],
}"
numberUnit="{/currencyCode}">
<attributes>
...
sap.ui.define(["sap/ui/core/mvc/Controller","sap/ui/model/type/Currency"],
function (Controller, Currency) {
"use strict";
},
formatStockValue: function(fUnitPrice, iStockLevel, sCurrCode) {
return oCurrency.formatValue([fUnitPrice * iStockLevel, sCurrCode], "string");
},
onItemSelected: function(oEvent) {
var oSelectedItem = oEvent.getSource();
var oContext = oSelectedItem.getBindingContext("products");
var sPath = oContext.getPath();
var oProductDetailPanel = this.getView().byId("productDetailsPanel");
oProductDetailPanel.bindElement({ path: sPath, model: "products" });
}
});
});
In the controller, we bind the newly created panel to the correct item whenever it is pressed.
We can now click on an element in the list and see its details in the panel below. We can even edit these details and these changes are directly shown in the
list because we use two-way binding.
Note
Element bindings can also be relative to its parent context.
...
# Screen titles
panel4HeaderText=Product Details
# Product list
productListTitle=Product List
stockValue=Current Stock Value
# Product Details
ProductID=Product ID
ProductName=Product Name
QuantityPerUnit=Quantity per Unit

UnitPrice=Unit Price
UnitsInStock=Number of Units in Stock
Discontinued=Discontinued
# Screen titles
panel4HeaderText=Produktdetails
# Product list
productListTitle=Artikelliste
stockValue=Lagerbestand Wert
# Product Details
ProductID=Produkt-ID
ProductName=Produktname
QuantityPerUnit=Mege pro Einheit
UnitPrice=Preis der Einheit
UnitsInStock=Lagerbestand
Discontinued=Eingestellt
Add the missing texts to the properties files.
Previous: Step 12: Aggregation Binding Using Templates
Next: Step 14: Expression Binding
Related Information
Element Binding

Expression binding allows you to display a value on the screen that has been calculated from values found in some model object. This way simple formatting
or calculations can be inserted directly into the data binding string. In this example, we will change the color of the price depending on whether it is above or
below some arbitrary threshold. The threshold value is also stored in the JSON model.
Preview
Figure 1: Values formatted
Coding

...
</content>
</Panel>
<content>
<List headerText="{i18n>invoiceListTitle}" class="sapUiResponsiveMargin" width="auto"
items="{/invoices}">
<items>
<ObjectListItem
title="{Quantity} x {ProductName}"
number="{ parts: [{path: 'ExtendedPrice'},
{path: '/currencyCode'}],
}"
numberUnit="{/currencyCode}"
numberState="{= ${products>UnitPrice} > ${/priceThreshold} ? 'Error' : 'Success' }">
<attributes>
<ObjectAttribute text="{ path: 'Status',
formatter: '.formatStatusText' }"/>
</attributes>
</ObjectListItem>
</items>
</List>
</content>
</Panel>
</mvc:View>
In the XML view, we add a new numberState property to the ObjectListItem element within the List. The value of this property is an expression that
will be evaluated for each item.
webapp/index.html
...
"priceThreshold" : 20,
...
We add a new property called priceThreshold against which each invoice value will be checked.
As a result of binding an expression to the numberState property, the error status (color) of the price field will change depending on the invoice value.
Look at the following two expressions:
numberState="{= ${products>UnitPrice} > ${/priceThreshold} ? 'Error' : 'Success' }">
numberState="{= ${products>UnitPrice} <= ${/priceThreshold} ? 'Success' : 'Error' }">
Can you see why one of these expressions will work, and the other will not?
Logically, both expressions are identical; yet the first one works, and the second does not: it produces only an empty screen and an "Invalid XML" message in
the browser's console Hmmm, what's going on here?
In order to understand why this situation occurs, you must understand how XML files are parsed.
When an XML file is parsed, certain characters have a special (that is, high priority) meaning to the XML parser. When such characters are encountered, they
are always interpreted to be part of the XML definition itself and not part of any other content that might exist within the XML document.
As soon as the XML parser encounters one of these high-priority characters (in this case, a less-than (<) character), it will always be interpreted as the start of
a new XML tag irrespective of any other meaning that character might have within the context of the expression. This is known as a syntax collision.
In this case, the collision occurs between the syntax of XML and the syntax of the JavaScript-like expression language used by SAPUI5.
Therefore, this statement fails because the less-than character is interpreted as the start of an XML tag: numberState="{= ${products>UnitPrice}
<= ${/priceThreshold} ? 'Success' : 'Error' }">
This particular problem can be avoided in one of two ways:
Reverse the logic of the condition (use "greater than or equal to" instead of "less than")
Use the escaped value for the less-than character: numberState="{= ${products>UnitPrice} <= ${/priceThreshold} ?
'Success' : 'Error' }">
Since the use of an escaped character is not so easy to read, the preferred approach is to reverse the logic of the condition and use a greater-than character
instead.
The ampersand (&) character also has a high priority meaning to the XML parser. This character will always be interpreted to mean "The start of an escaped
character". So if you wish to use the Boolean AND operator (&&) in a condition, you must escape both ampersand characters (&&).
Previous: Step 13: Element Binding
Next: Step 15: Aggregation Binding Using a Factory Function

Related Information
Expression Binding
1.3.3.15 Step 15: Aggregation Binding Using a Factory Function

Instead of hard-coding a single template control, we will use a factory function to generate different controls based on the data received at runtime. This
approach is much more flexible and allows complex or heterogeneous data to be displayed.
Preview
Figure 1: Controls generated based on data
Coding
...
<content>
<List id="ProductList" headerText="{i18n>productListTitle}" items="{
path: 'products>/Products',
factory: '.productListFactory'
}" />
</content>
</Panel>
...
The List XML element that previously held the product list is now reduced simply to a named, but otherwise empty placeholder. Without a factory function to
populate it, this List would always remain empty.
sap.ui.define([ "sap/ui/core/mvc/Controller", "sap/ui/model/type/Currency" ],
function(Controller, Currency) {
"use strict";

},
formatStockValue : function(fUnitPrice,
iStockLevel, sCurrCode) {
return oCurrency.formatValue([fUnitPrice * iStockLevel, sCurrCode ], "string");
},
onItemSelected : function(oEvent) {
var oSelectedItem = oEvent.getSource();
var oContext = oSelectedItem.getBindingContext("products");
var sPath = oContext.getPath();
var oProductDetailPanel = this.getView().byId("productDetailsPanel");
oProductDetailPanel.bindElement({path : sPath, model : "products"});
},
productListFactory : function(sId,oContext) {
var oUIControl = null;
// Define the item description

var sDescription = oContext.getProperty("ProductName") + " (" + oContext.getProperty("QuantityPerUnit") + ")";
// This item is out of stock and discontinued

// *and* discontinued?
if (oContext.getProperty("UnitsInStock") === 0 && oContext.getProperty("Discontinued")) {
// Yup, so use a
// StandardListItem
oUIControl = new sap.m.StandardListItem(sId, {
icon : "sap-icon://warning",
title : sDescription,
info : { path: "i18n>Discontinued" },
infoState : "Error"
});
} else {
// Nope, so we will create an
// ObjectListItem
oUIControl = new sap.m.ObjectListItem(sId, {

title : sDescription,
number : {
parts : [ "products>UnitPrice", "/currencyCode" ],
type : "sap.ui.model.type.Currency",
formatOptions : {
showMeasure : false
}
},
numberUnit : {
path : "/currencyCode"
}
});
// Is this item out of stock?

if (oContext.getProperty("UnitsInStock") < 1) {
// Nope, so this item is just temporarily out of stock
oUIControl.addAttribute(new sap.m.ObjectAttribute({
text : { path: "i18n>outOfStock" }
}));
}
}
// Set item active (so it is clickable) and attach the press event
// handler for showing the details
oUIControl.setType(sap.m.ListType.Active);
oUIControl.attachPress(this.onItemSelected, this);
return oUIControl;
}
});
});
In the App controller, we create a new function called productListFactory. The types of controls returned from this factory function must be limited to
those suitable for inclusion in the items aggregation of a sap.m.List object. In this case, we will return either a StandardListItem or an
ObjectListItem using the following logic:
We decide which type of control to return by checking the current stock level and whether or not the product has been discontinued. This creates the following
possible responses:
1. First, eliminate the minority case.
If the stock level is zero and the product has also been discontinued, then use a StandardListItem with a warning icon and a Product Discontinued
message in the status property. All other possibilities will use an ObjectListItem.

2. Create an ObjectListItem then for the remaining three possibilities.
The product is in stock and the product has not been discontinued. This is the majority case.
3. The stock level is zero, therefore we are temporarily out of stock. In this case, add a single ObjectAttribute that displays the Out of Stock
message.
...
# Product Details
...
outOfStock=Out of Stock
...
# Product Details
...
outOfStock=Nicht Vorrtig
We add the missing texts to the properties files.
That's all - you completed the Data Binding tutorial!
Previous: Step 14: Expression Binding
Related Information
Aggregation Binding
1.3.4 Navigation and Routing

SAPUI5 comes with a powerful routing API that helps you control the state of your application efficiently. This tutorial will illustrate all major features and APIs
related to navigation and routing in SAPUI5 apps by creating a simple and easy to understand mobile app. It represents a set of best practices for applying the
navigation and routing features of SAPUI5 to your applications.
In classical Web applications, the server determines which resource is requested based on the URL pattern of the request and serves it accordingly. The
server-side logic controls how the requested resource or page is displayed in an appropriate way.
In single-page applications, only one page is initially requested from the server and additional resources are dynamically loaded using client-side logic. The
user only navigates within this page. The navigation is persisted in the hash instead of the server path or URL parameters.
For example, a classical Web application might display the employees resume page when URL http://<your-host>/<some-path-to-the-
app>/employees/resume.html?id=3 or http://<your-host>/<some-path-to-the-app>/employees/3/resume is called. A single-page
application instead would do the same thing by using a hash-based URL like http://<your-host>/<some-path-to-the-
app>/#/employees/3/resume.
The information in the hash, namely everything that is following the # character, is interpreted by the router.
Note
This tutorial does not handle cross-app navigation with the SAP Fiori launchpad. However, the concepts described in this tutorial are also fundamental for
navigation and routing between apps in the SAP Fiori launchpad.
We will create a simple app displaying the data of a companys employees to show typical navigation patterns and routing features. The complete flow of the
application can be seen in the figure below. We'll start with the home page which lets users do the following:
Display a Not Found page
Navigate to a list of employees and drill further down to see a Details page for each employee
Show an Employee Overview that they can search and sort

Figure 1: Page flow of the final app
Throughout this tutorial we will add features for navigating to pages and bookmarking them. We will add backward and forward navigation with common
transition animations (slide, show, flip, etc.). We will add more pages to the app and navigate between them to show typical use cases. We will even learn how
to implement features for bookmarking a specific search, table sorting via filters, and dialogs.
Note
This tutorial is based on SAPUI5 version 1.30 or higher. The navigation features shown in this tutorial are available since version 1.28. However, the
configuration via the descriptor file manifest.json is only available since 1.30.
Tip
You don't have to do all tutorial steps sequentially, you can also jump directly to any step you want. Just download the code from the previous step, and
start there.
You can view and download the files for all steps in the Explored app in the Demo Kit under Navigation and Routing . Copy the code to your workspace
and make sure that the application runs by calling the webapp/index.html file. Depending on your development environment you might have to adjust
resource paths and configuration entries.
Prerequisites
Troubleshooting
1. Step 1: Set Up the Initial App

We start by setting up a simple app for this tutorial. The app displays mock data only and mimics real OData back-end calls with the mock server as
you have seen in the Walkthrough tutorial.
2. Step 2: Enable Routing
In this step we will modify the app and introduce routing. Instead of having the home page of the app hard coded we will configure a router to wire
multiple views together when our app is called. The routing configuration controls the application flow when the user triggers a navigation action or opens
a link to the application directly.
3. Step 3: Catch Invalid Hashes
Sometimes it is important to display an indication that the requested resource was not found. To give you an example: If a user tries to access an
invalid pattern which does not match any of the configured routes, the user is notified that something went wrong. You might also know this as a 404 or
Not Found Page from traditional web pages. In this step, we will implement a feature that detects invalid hashes and visualizes this in a nice way.
4. Step 4: Add a Back Button to Not Found Page
When we are on the Not Found page because of an invalid hash, we want to get back to our app to select another page. Therefore, we will add a Back
button to the Not Found view and make sure that the user gets redirected to either the previous page or the overview page when the Back button is
pressed.
5. Step 5: Display a Target Without Changing the Hash
In this step, you will learn more about targets and how to display a target from the routing configuration manually.
6. Step 6: Navigate to Routes with Hard-Coded Patterns
In this step, we'll create a second button on the home page, with which we can navigate to a simple list of employees. This example illustrates how to
navigate to a route that has a hard-coded pattern.
7. Step 7: Navigate to Routes with Mandatory Parameters
In this step, we implement a feature that allows the user to click on an employee in the list to see additional details of the employee. A route pattern can
have one or more mandatory parameters to identify objects in an app.
8. Step 8: Navigate with Flip Transition
In this step, we want to illustrate how to navigate to a page with a custom transition animation. Both forward and backward navigation will use the flip

transition but with a different direction. We will create a simple link on the Employee view that triggers a flip navigation to a page that displays the
resume data of a certain employee. Pressing the Back button will navigate back to the Employee view with a reversed flip transition.
9. Step 9: Allow Bookmarkable Tabs with Optional Query Parameters
The resume view contains four tabs as we have seen in the previous steps. However, when the user navigates to the resume page, only the first tab is
displayed initially. Navigating directly to a specific tab or bookmarking a tab is not yet supported in our current app.
10. Step 10: Implement Lazy Loading
In the previous steps, we have implemented a Resume view that uses tabs to display data. The complete content of the tabs is loaded once, no matter
which tab is currently displayed. We can increase the performance of our app by avoiding to load content that is not visible. Therefore, we implement a
lazy loading feature that only loads the view and data when requested by the user.
11. Step 11: Assign Multiple Targets
In this step, we will add a new button to the home page to illustrate the usage of multiple targets for a route. When the button is pressed, a new page
opens that contains two parts: a header part at the top and a content part. The content part displays a table of employees that can be sorted and
searched. We will use the array notation in the routing configuration to assign multiple targets to a route - a feature that we have not yet introduced.
12. Step 12: Make a Search Bookmarkable
In this step we will make the search bookmarkable. This allows users to search for employees in the Employees table and they can bookmark their
search query or share the URL.
13. Step 13: Make Table Sorting Bookmarkable
In this step, we will create a button at the top of the table which will change the sorting of the table. When the current sorting state of the table is
changed, the sorting state will be reflected in the URL. This illustrates how to make the table sorting bookmarkable.
14. Step 14: Make Dialogs Bookmarkable
In this step, we want to allow bookmarking of the dialog box that is opened when the user clicks the Sort button. The dialog should automatically open
when the URL contains the query parameter showDialog.
15. Step 15: Reuse an Existing Route
The Employees table displays employee data. However, the resumes of the employees are not accessible from this view yet. We could create a new
route and a new view to visualize the resume again, but we could also simply reuse an existing route to cross-link the resume of a certain employee. In
this step, we will add a feature that allows users to directly navigate to the resume of a certain employee. We will reuse the Resume page that we have
created in an earlier step. This example illustrates that there can be multiple navigation paths that direct to the same page.
16. Step 16: Handle Invalid Hashes by Listening to Bypassed Events
So far we have created many useful routes in our app. In the very early steps we have also made sure that a Not Found page is displayed in case the
app was called with an invalid hash. Now, we proceed further and track invalid hashes to be able to detect and correct any invalid links or add new URL
patterns that are often requested but not found. Therefore, we simply listen to the bypassed events
17. Step 17: Listen to Matched Events of Any Route
In the previous step, we have listened for bypassed events to detect possible technical issues with our app. In this step, we want to improve the
analysis use case even more by listening to any matched event of the route. We could use this information to measure how the app is used and how
frequently the pages are called. Many Web analytic tools track page hits this way. The collected information can be used, for example to improve our
app and its usability.
18. Summary
You have now completed the tutorial "Navigation and Routing" for SAPUI5.
1.3.4.1 Step 1: Set Up the Initial App

We start by setting up a simple app for this tutorial. The app displays mock data only and mimics real OData back-end calls with the mock server as you have
seen in the Walkthrough tutorial.
The structure and data model created in this step will be used throughout the rest of this tutorial. The initial app created in this step will be extended in the
subsequent steps to illustrate the navigation and routing features of SAPUI5
Preview
Figure 1: Initial app with a simple button
Coding
To set up your project for this tutorial, download the files for Step 1 from the Explored app in the Demo Kit under Navigation and Routing - Step 1 . Copy
the code to your workspace and make sure that the application runs by calling the webapp/index.html file.
Depending on your development environment you might have to adjust resource paths and configuration entries. The project structure and the files coming with
this tutorial are explained in detail in the Walkthrough tutorial.
You should have the same files as displayed in the following figure:

Figure 2: Folder structure with downloaded files
Note
The content of the localService folders will not be changed in this tutorial. The i18n folder will always contain the i18n.properties file only.
Therefore, we will show both subfolders collapsed in the following steps.
The Initial App

With the downloaded coding, you have an initial app with recommended settings that provides the basic features of an SAPUI5 app:
Home Page
The home page of our app is defined in the webapp/index.html file. In this file we bootstrap SAPUI5 and tell the runtime where to find our custom
resources. Furthermore, we initialize the MockServer to simulate back-end requests as we do not have a real back-end service throughout this tutorial.
Finally, we instantiate the application component, assign it to a sap.m.Shell control, and place the shell into the body. The corresponding
Components.js file in the webapp folder will be extended throughout this tutorial.
Data
In the webapp/localService/mockserver.js file, we configure the mock server. Using the mock server in this tutorial allows us to easily run the
code even without network connection and without the need of having a remote server for our application data.
The metadata.xml file used by the mock server describes our OData service. The service only has two OData entities:
Employee
An employee has typical properties like FirstName and LastName as well as a navigation property to a resume entity referenced by a
ResumeID. Of course, the entity also has an ID property: EmployeeID. The corresponding EntitySet is Employees. The actual test data
containing several employees is located in the webapp/localService/mockdata/Employees.json file.
Resume
In our case, we want to keep the resume of employees very simple. Therefore, we just have simple properties of type Edm.String. The
properties are Information, Projects, Hobbies and Notes; all of them contain textual information. The entity has an ID property ResumeID
and the corresponding EntitySet is Resumes. The resume data for an employee is located in file
webapp/localService/mockdata/Resumes.json.
Configuration of the App
In the webapp/manifest.json descriptor file, we configure our app. The descriptor file contains the following most interesting sections:
sap.app
In this section we reference an i18n.properties file and use a special syntax to bind the texts for the title and description properties.
In the dataSources part, we tell our app where to find our OData service employeeRemote. As you might guess, the uri correlates to the
rootUri of our mock server instance which can be found in webapp/localService/mockserver.js. It is important that these two paths
match to allow our mock server to provide the test data we defined above. The localUri is used to determine the location of the
metadata.xml file.
sap.ui5
Under sap.ui5 we declare with the rootView parameter that our sap.ui.demo.nav.view.App view shall be loaded and used as the
rootView for our app. Furthermore, we define two models to be automatically instantiated and bound to the i18n component and a default
model "". The latter references our employeeRemote dataSource which is declared in our sap.app section as an OData 2.0 data source.
The i18n file can be found at webapp/i18n/i18n.properties. This data source will be mocked by our mock server.
So far we have a basic app that does not really have any navigation or routing implemented. This will change in the next steps when we implement our first
navigation features.
Parent topic: Navigation and Routing
Next: Step 2: Enable Routing
1.3.4.2 Step 2: Enable Routing

In this step we will modify the app and introduce routing. Instead of having the home page of the app hard coded we will configure a router to wire multiple
views together when our app is called. The routing configuration controls the application flow when the user triggers a navigation action or opens a link to the
application directly.

Preview
Figure 1: Views are wired together using the router
Coding
You can view and download all files in the Explored app in the Demo Kit under Routing and Navigation - Step 2 .
Figure 2: Folder structure for this step
{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
"_version": "1.1.0",
"rootView": "sap.ui.demo.nav.view.App",
"dependencies": {
...
},
"models": {
...
},
"routing": {
"config": {
"viewType": "XML",
"viewPath": "sap.ui.demo.nav.view",
"controlId": "app",
"controlAggregation": "pages",
"transition": "slide"
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"
}],
"targets": {
"home": {
"viewName": "Home",
"viewLevel" : 1
}
}
}
}
}

Single-page applications based on SAPUI5 can use a so-called router to dispatch hash-based URLs to one or more views of the app. Therefore, the router
needs to know how to address and show the views. In SAPUI5, we can simply add a routing section to our existing sap.ui5 section in the descriptor file
to configure the router. There are three properties that can be used to configure the routing of your application:
config
This section contains the global router configuration and default values that apply for all routes and targets. The default value for routerClass is
sap.ui.core.routing.Router. We set the routerClass to sap.m.routing.Router because we implement an app based on sap.m.
Furthermore, we define where our views are located in the app. To load and display views automatically, we also specify the controlId of the control
that is used to display the pages and the aggregation (controlAggregation) that will be filled when a new page is displayed. We will create only
XMLviews in this tutorial, so we can set the viewType property to XML. All our views will be available in the view folder of the namespace
sap.ui.demo.nav, so we can set the viewPath to sap.ui.demo.nav.view. The transition allows us to set a default value for how the
transition should happen; you can choose between slide (default), flip, fade, and show. All parameters of the config section can be overruled in the
individual route and target definitions if needed.
Note
The possible values for routerClass are sap.ui.core.routing.Router, sap.m.routing.Router, or any other subclasses of
sap.ui.core.routing.Router. Compared to sap.ui.core.routing.Router the sap.m.routing.Router is optimized for mobile apps
and adds the properties viewLevel, transition and transitionParameters which can be specified for each route or target created by the
sap.m.routing.Router. The transitionParameters can also be used for custom transitions. Please check the API Reference for more
information.
routes
Each route defines a name, a pattern, and one or more targets to navigate to when the route has been hit. The pattern is basically the hash part of the
URL that matches the route. The sequence of the routes is important because only the first matched route is used by the router. In our case, we have an
empty pattern to match the empty hash. The name property allows you to choose a unique route name that helps you to navigate a specific route or to
determine the matched route in one of the matched handlers (we'll explain that in a later step). The target property references one or more targets from
the section below that will be displayed when the route has been matched.
targets
A target defines the view that is displayed. It is associated with one or more routes or it can be displayed manually from within the app. Whenever a
target is displayed, the corresponding view is loaded and added to the aggregation configured with the controlAggregation option of the control.
This option is configured using controlId. Each target has a unique key (home). The viewName defines which view shall be loaded. In our little
example, the absolute view path to be loaded for our home target is determined by the default "viewPath": "sap.ui.demo.nav.view" and
"viewName": "Home". This leads to "sap.ui.demo.nav.view.Home". The viewLevel is especially relevant for flip and slide transitions. It
helps the router to determine the direction of the transition from one page to another. (This will also be explained later.) A target can be assigned to a
route, but it's not necessary. Targets can be displayed directly in the app without hitting a route.
This basic routing configuration was easy enough. However, you cant see it in action until you have initialized the router.
Note
As of SAPUI5 version 1.30, we recommend that you define the routing in the manifest.json descriptor file using routes and targets. In older versions of
SAPUI5, the routing configuration had to be done directly in the metadata section of the component, and with different syntax.
webapp/Component.js
sap.ui.define([
"sap/ui/core/UIComponent"
], function (UIComponent) {
"use strict";
return UIComponent.extend("sap.ui.demo.nav.Component", {
metadata: {
manifest: "json"
},
init: function () {

}
});
});
We override the init function and call the parents init function first. We get a reference to the router and call initialize() on it. The router is
instantiated automatically with the configuration loaded in the descriptor. The routing events and our configuration in the descriptor are now automatically
enabled in the app. Running the app at this point would lead to an error, because the home view is not implemented yet.
<mvc:View
controllerName="sap.ui.demo.nav.controller.App"
xmlns="sap.m"
<App id="app"/>

</mvc:View>
In the App view, we remove the content of App control. The pages will be added dynamically the way we have configured it in the descriptor. The view
configured with the property rootView is automatically instantiated when the app is called initially.
webapp/view/Home.view.xml (New)
<mvc:View
controllerName="sap.ui.demo.nav.controller.Home"
xmlns="sap.m"
<Page title="{i18n>homePageTitle}" class="sapUiResponsiveContentPadding">
<content>
<Button text="{i18n>iWantToNavigate}" class="sapUiTinyMarginEnd"/>
</content>
</Page>
</mvc:View>
Create a file Home.view.xml in the webapp/view folder. The home view only contains a page control that displays a button. For illustration, we bind the
title of the page to the i18n>homePageTitle, you can use data binding just the way you are used to it.
webapp/controller/Home.controller.js (New)
sap.ui.define([
"use strict";
return Controller.extend("sap.ui.demo.nav.controller.Home", {
});
});
Create a file Home.controller.js in the webapp/controller folder. The controller for the home view does not contain any custom logic in this step,
but we will add some features to it soon. Finally, run the app by calling the webapp/index.html file. This will be the entry point for our app in all the next
steps. As you can see, the app is initially displaying the home view that we configured as the default pattern in the routing configuration. We have now
successfully enabled routing in the app.
Note
We think of routing as a set of features that dispatch hash-based URLs to an app's views and manage the views' states.
Based on the routing configuration, you define the navigation between pages and pass parameters to the target views.
Conventions
Configure the router in the manifest.json descriptor file
Initialize the router exactly once
Initialize the router in the component
Previous: Step 1: Set Up the Initial App
Next: Step 3: Catch Invalid Hashes
Related Information
1.3.4.3 Step 3: Catch Invalid Hashes

Sometimes it is important to display an indication that the requested resource was not found. To give you an example: If a user tries to access an invalid
pattern which does not match any of the configured routes, the user is notified that something went wrong. You might also know this as a 404 or Not Found
Page from traditional web pages. In this step, we will implement a feature that detects invalid hashes and visualizes this in a nice way.
Preview

Figure 1: Not Found page
Coding
{
...
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"transition": "slide",
"bypassed": {
"target": "notFound"
}
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"
}],
"targets": {
"home": {
"viewName": "Home",
"viewLevel" : 1
},
"notFound": {
"viewName": "NotFound",
"transition": "show"
}
}
}
}
}

Lets extend the routing configuration in the descriptor by adding a bypassed property and setting its target to notFound. This configuration tells the router
to display the notFound target in case no route was matched to the current hash. Next, we add a notFound target to the bypassed section. The
notFound target simply configures a notFound view with a show transition.
webapp/view/NotFound.view.xml (New)
<mvc:View
controllerName="sap.ui.demo.nav.controller.NotFound"
xmlns="sap.m"
<MessagePage
title="{i18n>NotFound}"
text="{i18n>NotFound.text}"
description="{i18n>NotFound.description}"/>
</mvc:View>
Now we create the view referenced above in a new file NotFound.view.xml in the webapp/view folder. It uses a sap.m.MessagePage control to
display an error message to the user. In a real app you might use a dynamic message matchint the current error situation. Here, we simply display a
preconfigured text from our resource bundle.
webapp/controller/NotFound.controller.js (New)
sap.ui.define([
"use strict";
return Controller.extend("sap.ui.demo.nav.controller.NotFound", {
}
});
});
Now we create the controller for the NotFound view and save it into the webapp/controller folder. This controller will be extended later.
...
NotFound=Not Found
NotFound.text=Sorry, but the requested resource is not available.
NotFound.description=Please check the URL and try again.
Add the new properties to the i18n.properties file.
Open the URL index.html/#/thisIsInvalid in your browser. From now on the user will see a nice Not Found page if a hash could not be matched to
one of our routes.
Conventions
Always configure the bypassed property and a corresponding target
Use the sap.m.MessagePage control to display routing related error messages
Previous: Step 2: Enable Routing
Next: Step 4: Add a Back Button to Not Found Page
Step 4: Add a Back Button to Not Found Page

When we are on the Not Found page because of an invalid hash, we want to get back to our app to select another page. Therefore, we will add a Back
button to the Not Found view and make sure that the user gets redirected to either the previous page or the overview page when the Back button is pressed.
Preview

Figure 1: Not Found page with Back button
Coding
webapp/view/NotFound.view.xml
<mvc:View
controllerName="sap.ui.demo.nav.controller.NotFound"
xmlns="sap.m"
<MessagePage
title="{i18n>NotFound}"
text="{i18n>NotFound.text}"
description="{i18n>NotFound.description}"
navButtonPress="onNavBack"/>
</mvc:View>
In the NotFound view, we set the property showNavButton of the MessagePage control to true to automatically display the Back button. We also add
an event handler function onNavBack to the navButtonPress event of the control. The onNavBack function will handle the actual back navigation. We
could directly add this function to the views controller. However, we are smart enough to anticipate that we might need the same handler function for different
views. DRY (Dont Repeat Yourself) is the right approach for us, so lets create a BaseController from which all other controllers will inherit.
webapp/controller/BaseController.js (New)
sap.ui.define([
"sap/ui/core/routing/History"
], function (Controller, History) {
"use strict";
return Controller.extend("sap.ui.demo.nav.controller.BaseController", {
getRouter : function () {
return sap.ui.core.UIComponent.getRouterFor(this);
},
onNavBack: function (oEvent) {
var oHistory, sPreviousHash;
oHistory = History.getInstance();
sPreviousHash = oHistory.getPreviousHash();
if (sPreviousHash !== undefined) {
window.history.go(-1);
} else {
this.getRouter().navTo("appHome", {}, true /*no history*/);
}
}
});
});
Create a new BaseController.js file in the webapp/controller folder. The base controller implements a set of functions that are reused by its
subclasses. The onNavBack handler is a great example of code that we dont want to duplicate in our controllers for each page that has a back navigation.
The function checks if there is a previous hash value in the app history. If so, it redirects to the previous hash via the browsers native History API. In case
there is no previous hash we simply use the router to navigate to the route appHome which is our home view.
The third parameter of navTo("appHome", {}, true /*no history*/); has the value true and makes sure that the hash is replaced. With the line
sap.ui.core.UIComponent.getRouterFor(this) you can easily access your components router throughout the app. To make it even more
comfortable, we also add a handy shortcut getRouter to the base controller. This function is now available in each subclass as well. It is also used in the
onNavBack handler to get a reference to the router before calling navTo. We now have to implement the reuse in all other controllers.
Note
In SAPUI5 there are multiple options to reuse code. We recommend to use a base controller for such helper methods because this allows us to

decoratively use the onNavBack handler directly in any XML view without adding additional code to the controller. Our base controller is an abstract
controller that will not be instantiated in any view. Therefore, the naming convention *.controller.js does not apply, and we can just call the file
BaseController.js. By not using the naming convention *.controller.js we can even prevent any usage in views.
webapp/controller/NotFound.controller.js
sap.ui.define([
"sap/ui/demo/nav/controller/BaseController"
], function (BaseController) {
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.NotFound", {
}
});
});
In order to reuse the base controller implementation, we have to change the dependency from sap/ui/core/mvc/Controller to
sap/ui/demo/nav/controller/BaseController and directly extend the base controller.
At this point you can open index.html#/thisIsInvalid in your browser and press the Back button to see what happens. You will be redirected to the
apps home page that is matched by the route appHome as you opened the Not Found page with an invalid hash. If you change the hash to something invalid
when you are on the home page of the app, you will also go to the Not Found page but with a history entry. When you press back, you will get to the home
page again, but this time with a native history navigation.
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.App", {
}
});
});
To be consistent, we will now extend all of our controllers with the base controller. Change the app controller as described above.
webapp/controller/Home.controller.js
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.Home", {
});
});
The same applies to our home controller, we also extend it with the base controller now.
Note
In this step we have added the Back button. The user can always use the browsers native Back button as well. Each app can freely configure the
behavior of the Back button. However, there is no clean way to apply the same logic for the browsers Back button in single-page applications. Tweaking
the browser history or using other quirks for cancelling backward or forward navigation is not recommended due to the implementation details of the
browsers. The browsers Back button always uses the browser history while the Back button of the app can make use of the browser history or can
implement its own navigation logic. Make sure to understand this difference and only control the Back button inside the app.
Conventions
Implement a global onNavBack handler for back navigation in your app
Query the history and go to the home page if there is no history available for the current app
Previous: Step 3: Catch Invalid Hashes
Next: Step 5: Display a Target Without Changing the Hash
Related Information
1.3.4.5 Step 5: Display a Target Without Changing the Hash

In this step, you will learn more about targets and how to display a target from the routing configuration manually.
We will display the Not Found target from the previous step without changing the hash to illustrate this navigation pattern. We will also consider a side-effect
that prevents us from navigating back in this case.
Fortunately, we can extend our app and offer an easy solution. There are some use cases that should not be persisted in the URL but just be triggered by the
application logic if needed. A target is a navigation-related configuration for a view and we can display targets manually without referencing them in a
navigation route. Good examples for this are temporary errors, switching to an edit page for a business object, or going to a Settings page. Sometimes you
will also have to implement a way back manually.
Preview
Figure 1: The new Home page with a navigation button
Coding
You can view and download all files in the Explored app in the Demo -kit under Routing and Navigation - Step 5 .
webapp/view/Home.view.xml
<mvc:View
xmlns="sap.m"
<content>
<Button id="displayNotFoundBtn" text="{i18n>DisplayNotFound}" press="onDisplayNotFound" class="sapUiTinyMarginEnd"
</content>
</Page>
</mvc:View>
We start by changing the Button control from the home view. When the button is pressed the onDisplayNotFound handler is called.
sap.ui.define([
"use strict";
onDisplayNotFound : function (oEvent) {
//display the "notFound" target without changing the hash
this.getRouter().getTargets().display("notFound");
}
});
});
Inside the onDisplayNotFound handler we get a reference to the Targets helper object of the router and simply call display("notFound"). The view
associated to the target with the name notFound from the routing configuration will be displayed by the router without changing the hash.
The sap.m.routing.Targets object itself can be retrieved by calling getTargets() on the router. It provides a convenient way for placing views into the
correct containers of your application. The main benefits of targets are structuring and lazy loading: you just configure the views in the routing configuration
and you do not have to load the views until you really need them.
Note
In the example code we get a reference to the sap.m.routing.Targets object by calling getTargets() on this.getRouter() from the base
controller. However, you could also get a reference to the sap.m.routing.Targets object by calling
this.getOwnerComponent().getRouter().getTargets() or this.getOwnerComponent().getTargets().
If you now call the app and press the Display Not Found button you see that the notFound target is displayed without changing the URL. That was easy, but
suddenly our apps Back button does not work anymore. The bug we have just introduced illustrates an interesting navigation trap. The application hash is
still empty since we just display the target and did not hit a route.
When pressing the apps Back button, the onNavBack from the previous step is called. It detects that there is no previous hash and therefore tries to
navigate to the appHome route again. The router is smart enough to detect that the current hash did not change and therefore skips the navigation to the route.
Fortunately, there is an easy workaround for us. However, we need to touch the Home controller again.

webapp/controller/Home.controller.js (Changed Again)
sap.ui.define([
"use strict";
//display the "notFound" target without changing the hash
this.getRouter().getTargets().display("notFound", {
fromTarget : "home"
});
}
});
});
This time we pass on a data object as the second parameter for the display method which contains the name of the current target; the one from which we
navigate to the notFound target. We decide to choose the key fromTarget but since it is a custom configuration object any other key would be fine as well.
webapp/controller/NotFound.controller.js
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.NotFound", {
var oRouter, oTarget;
oRouter = this.getRouter();
oTarget = oRouter.getTarget("notFound");
oTarget.attachDisplay(function (oEvent) {
this._oData = oEvent.getParameter("data"); //store the data
}, this);
},
// override the parent's onNavBack (inherited from BaseController)
onNavBack : function (oEvent){
var oHistory, sPreviousHash, oRouter;
// in some cases we could display a certain target when the back button is pressed
if (this._oData && this._oData.fromTarget) {
this.getRouter().getTargets().display(this._oData.fromTarget);
delete this._oData.fromTarget;
return;
}
// call the parent's onNavBack
BaseController.prototype.onNavBack.apply(this, arguments);
}
});
});
Next, we have to register an event listener to the display event of the notFound target. The best place for us to register an event listener for this is inside
the init function of our NotFound controller. There we can access and store the custom data that we are passing on when displaying the target manually.
From the router reference we can fetch a reference to the notFound target. Each target configuration will create a runtime object that can be accessed
through the router.
Similar to SAPUI5 controls, targets define API methods and events that can be attached. We attach a display event handler and save the data that was
received as the event parameter data in an internal controller variable _oData. This data also includes the fromTarget information in case the caller
passed it on. However, we now have to override the base controllers onNavBack implementation to change the behavior a bit. We add a special case for our
target back functionality in case the fromTarget property has been passed on. If specified, we simply display the target defined as fromTarget manually
the same way we actually called the notFound target manually. Otherwise we just call the base controllers onNavBack implementation.
...
DisplayNotFound=Display Not Found
Add the new property to the i18n.properties file.
When we now click the Back button, it works as expected and brings us back to the overview page, also when the Not Found view is displayed manually.
Conventions
Display targets manually if you want to trigger a navigation without changing the hash
Think carefully about all navigation patterns in your application, otherwise the user might get stuck
Previous: Step 4: Add a Back Button to Not Found Page
Next: Step 6: Navigate to Routes with Hard-Coded Patterns

In this step, we'll create a second button on the home page, with which we can navigate to a simple list of employees. This example illustrates how to navigate
to a route that has a hard-coded pattern.
Preview
Figure 1: Show Employee List button on the Home page
Figure 2: Employee list with Back button
Coding
<mvc:View
xmlns="sap.m"

<content>
<Button id="displayNotFoundBtn" text="{i18n>DisplayNotFound}" press="onDisplayNotFound" class="sapUiTinyMarginEnd"/>
<Button id="employeeListBtn" text="{i18n>ShowEmployeeList}" press="onNavToEmployees" class="sapUiTinyMarginEnd"/>
</content>
</Page>
</mvc:View>
First, we change the Home view by adding the Show Employee List button. We register an event handler onNavToEmployees for the press event.
sap.ui.define([
"use strict";
// display the "notFound" target without changing the hash
this.getRouter().getTargets().display("notFound", {
fromTarget : "home"
});
},
onNavToEmployees : function (oEvent){
this.getRouter().navTo("employeeList");
}
});
});
The new event handler onNavToEmployees calls navTo("employeeList") on the router instance. The parameter employeeList is the name of the
route that we want to navigate to.
{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"bypassed": {
}
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"
}, {
"pattern": "employees",
"name": "employeeList",
"target": "employees"
}],
"targets": {
"home": {
"viewName": "Home",
"viewLevel" : 1
},
"notFound": {
},
"employees": {
"viewPath": "sap.ui.demo.nav.view.employee",
"viewName": "EmployeeList",

"viewLevel" : 2
}
}
}
}
}
To make the navigation work, we have to extend the routing configuration of the app in the descriptor file. We add a new pattern called employeeList; this is
the name we used in the controller to trigger the navigation.
The pattern of the route is the hard-coded value employees, meaning the matching hash for this route is /#/employees in the address bar of the browser.
The target employees should be displayed when this URL pattern is matched.
The employees entry in the targets section references the sap.ui.demo.nav.view.employee.EmployeeList view. As you can see, we added a
new namespace employee for all views related to employees with the property viewPath. This overrides the default settings in the config section for the
current target.
The view that we are about to create has to be placed in the webapp/view/employee folder accordingly. This approach helps to structure the views of the
app according to business objects and to better understand the navigation patterns of the app in larger projects.
Note
We could also have left out the viewPath property to use the default viewPath defined in the config section. In that case, we would have to change
the viewName to employee.EmployeeList to achieve the same effect.
Setting the viewLevel to 2 helps the router to determine how to animate the (in our case) slide transition. For us, this means that a navigation from the
home page to the employees target will be animated with a Slide to Left animation. In contrast to that, the back navigation from the employees target to
the home page will be animated with a Slide to Right animation. This behavior is due to the fact that the home page has a lower viewLevel than the
employees target.
webapp/view/employee/EmployeeList.view.xml (New)
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.EmployeeList"
xmlns="sap.m"
<Page id="employeeListPage" title="{i18n>EmployeeList}"
navButtonPress="onNavBack"
class="sapUiResponsiveContentPadding">
<content>
<List id="employeeList" headerText="{i18n>ListOfAllEmployees}" items="{/Employees}">
<items>
<StandardListItem
title="{FirstName} {LastName}"
iconDensityAware="false"
iconInset="false"/>
</items>
</List>
</content>
</Page>
</mvc:View>
We now create a subfolder employee below webapp/view and a file EmployeeList.view.xml.
We name the folder after the business object, to make it obvious from looking at the hash (included in the browser's address bar) where a view file for a certain
business object is located. For example, we can determine from the URL /#/employee that the corresponding view must be somewhere in the folder
./employee (in our case: webapp/view/employee) just by looking at the URL.
In the view, we use a sap.m.List control and bind its items to the data from our simulated OData service. Note that we have also registered the
onNavBack handler from the base controller again to be able to navigate back to the overview.
This view can be referenced by sap.ui.demo.nav.view.employee.EmployeeList.
webapp/controller/employee/EmployeeList.controller.js (New)
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.employee.EmployeeList", {
});
});
Finally, we will add a new controller. Create a subfolder employee inside webapp/controller folder and place the file EmployeeList.controller.js
there. As you can see, the folder structure of the controllers is in sync with the folder structure of the views.
...
ShowEmployeeList=Show Employee List

EmployeeList=Employee List
ListOfAllEmployees=List of all employees
Add the new texts to the i18n.properties file.
Now you can open the app and press the Show Employee List button to navigate to the employee list. From there, you can press either the browsers or the
apps Back button to get back to the home page.
Previous: Step 5: Display a Target Without Changing the Hash
Next: Step 7: Navigate to Routes with Mandatory Parameters
Related Information
Method and Events for Navigation
1.3.4.7 Step 7: Navigate to Routes with Mandatory Parameters

In this step, we implement a feature that allows the user to click on an employee in the list to see additional details of the employee. A route pattern can have
one or more mandatory parameters to identify objects in an app.
The detail page has to read the ID of the employee from the URL to fetch and display the employee data from the server. If the employee was not found, for
example, because an invalid employee ID was passed on, we want to inform the user by displaying the notFound target. Of course, the back navigation has
to work as well for this page.
Preview
Figure 1: Employee list with navigation option for items
Figure 2: Detail Page for a selected employee

Figure 3: Not Found page for an invalid EmployeeID
Coding
{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"bypassed": {
}
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"

}, {
}, {
"pattern": "employees/{employeeId}",
"name": "employee",
"target": "employee"
}],
"targets": {
"home": {
"viewName": "Home",
"viewLevel" : 1
},
"notFound": {
},
"employees": {
"viewLevel" : 2
},
"employee": {
"viewName": "employee.Employee",
"viewLevel" : 3
}
}
}
}
}
From our data model (webapp/localService/metadata.xml or webapp/localService/mockdata/Employees.json), you can see that each
employee entity is identified by an EmployeeID. We define a new route that expects a mandatory employeeId in its pattern to address an employee. Unlike
the patterns we used before, this pattern has a dynamic part. We create a new route employee and use employees/{employeeId} as its pattern.
The {employeeId} part of the pattern is a mandatory parameter as indicated by the curly brackets. The hash that contains an actual employee ID is
matched against that pattern at runtime.
The following hashes would match in our case: employees/2, employees/7, employees/anInvalidId, and so on. However, the hash employees/
will not match as it does not contain an ID at all. The target of our route is employee. We create the target employee with viewLevel 3. With that, we
make sure that we have the correct slide animation direction.
Next, we have to create the view employees.Employee; for better illustration the viewPath is not specified this time.
webapp/view/employee/Employee.view.xml (New)
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.Employee"
xmlns="sap.m"
xmlns:f="sap.ui.layout.form"
busyIndicatorDelay="0">
<Page
id="employeePage"
title="{i18n>EmployeeDetailsOf} {FirstName} {LastName}"
<content>
<Panel
id="employeePanel"
width="auto"
class="sapUiResponsiveMargin sapUiNoContentPadding">
<headerToolbar>
<Toolbar>
<Title text="{i18n>EmployeeIDColon} {EmployeeID}" level="H2"/>
<ToolbarSpacer />
</Toolbar>
</headerToolbar>
<content>
<f:SimpleForm
minWidth="1024"
editable="false"
layout="ResponsiveGridLayout"
labelSpanL="3" labelSpanM="3" emptySpanL="4" emptySpanM="4"
columnsL="1" columnsM="1">
<f:content>
<Label text="{i18n>FirstName}" />
<Text text="{FirstName}" />

<Label text="{i18n>LastName}" />
<Text text="{LastName}" />
<Label text="{i18n>Address}" />
<Text text="{Address}" />
<Label text="{i18n>City}" />
<Text text="{City}, {Region}" />
<Label text="{i18n>PostalCode}" />
<Text text="{PostalCode}" />
<Label text="{i18n>PhoneHome}" />
<Text text="{HomePhone}" />
<Label text="{i18n>Country}" />
<Text text="{Country}" />
</f:content>
</f:SimpleForm>
</content>
</Panel>
</content>
</Page>
</mvc:View>
Create the file Employee.view.xml inside the webapp/view/employee folder. This employee view displays master data for an employee in a panel with
a SimpleForm control: first name, last name and so on. The data comes from a relative data binding that is set on the view level as we can see in the
controller later. As we are focusing on the navigation aspects in this tutorial, we wont go into detail on the controls of the view. Just copy the code.
webapp/controller/employee/Employee.controller.js (New)
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.employee.Employee", {
var oRouter = this.getRouter();
oRouter.getRoute("employee").attachMatched(this._onRouteMatched, this);
// Hint: we don't want to do it this way
/*
oRouter.attachRouteMatched(function (oEvent){
var sRouteName, oArgs, oView;
sRouteName = oEvent.getParameter("name");
if (sRouteName === "employee"){
this._onRouteMatched(oEvent);
}
}, this);
*/
},
_onRouteMatched : function (oEvent) {
var oArgs, oView;
oArgs = oEvent.getParameter("arguments");
oView = this.getView();
oView.bindElement({
path : "/Employees(" + oArgs.employeeId + ")",
events : {
change: this._onBindingChange.bind(this),
dataRequested: function (oEvent) {
oView.setBusy(true);
},
dataReceived: function (oEvent) {
oView.setBusy(false);
}
}
});
},
_onBindingChange : function (oEvent) {
// No data for the binding
if (!this.getView().getBindingContext()) {
}
}
});
});
Now we create the file Employee.controller.js in the webapp/controller/employee folder. In this controller file, we want to detect which
employee shall be displayed in order to show the employees data in the view. Therefore, we query the router for the route employee and attach a private
event listener function _onRouteMatched to the matched event of this route.
In the event handler, we can access the arguments parameter from the oEvent parameter that contains all parameters of the pattern. Since this listener is
only called when the route is matched, we can be sure that the mandatory parameter employeeId is always available as a key in arguments; otherwise the
route would not have matched. The name of the mandatory parameter employeeId correlates to the {employeeId} from our pattern definition of the route
employee and thus to the value in the URL.

In _onRouteMatched we call bindElement() on the view to make sure that the data of the specified employee is available in the view and its controls.
The ODataModel will handle the necessary data requests to the back end in the background. While the data is loading, it would be nice to show a busy
indicator by simply setting the view to busy. Therefore, we pass an events object to bindElement() to listen to the events dataRequested and
dataReceived. The attached functions handle the busy state by calling oView.setBusy(true) and oView.setBusy(false) respectively.
We also add an event handler to the change event as a private function _onBindingChange. It checks if the data could be loaded by querying the binding
context of the view. As seen in the previous steps, we will display the notFound target if the data could not be loaded.
Note
Instead of calling attachMatched() on a route we could also call attachRouteMatched() directly on the router. However, the event for the latter
is fired for every matched event of any route in the whole app. We dont use the latter because we would have to implement an additional check for making
sure that current route is the route that has been matched. We want to avoid this extra overhead and register on the route instead.
webapp/view/employee/EmployeeList.view.xml
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.EmployeeList"
xmlns="sap.m"
<Page id="employeeListPage" title="{i18n>EmployeeList}"
<content>
<List id="employeeList" headerText="{i18n>ListOfAllEmployees}" items="{/Employees}">
<items>
<StandardListItem
title="{FirstName} {LastName}"
iconDensityAware="false"
iconInset="false"
type="Navigation"
press="onListItemPressed"/>
</items>
</List>
</content>
</Page>
</mvc:View>
Its time to change the EmployeeList view so that we can navigate to the new view. We set the attribute type of the StandardListItem template to
Navigation to make the item clickable and indicate a navigation feature to the user. Additionally, we add an event handler for the press event that is called
when the user clicks on an employee list item.
webapp/controller/employee/EmployeeList.controller.js
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.employee.EmployeeList", {
onListItemPressed : function(oEvent){
var oItem, oCtx;
oItem = oEvent.getSource();
oCtx = oItem.getBindingContext();
this.getRouter().navTo("employee",{
employeeId : oCtx.getProperty("EmployeeID")
});
}
});
});
Finally, we add the handler onListItemPressed for the press event to the EmployeeList controller. In the handler, we determine the EmployeeID of
the list item by querying the binding context and accessing the property EmployeeID from the data model.
Then we navigate to the employee route and pass a configuration object on to the navTo method with the mandatory parameter employeeId filled with the
correct EmployeeID. The router always makes sure that mandatory parameters as specified in the routes pattern are set; otherwise an error is thrown.
...
EmployeeDetailsOf=Employee Details of
EmployeeIDColon=Employee ID:
FirstName=First Name
LastName=Last Name
Address=Address
City=City
PostalCode=Postal Code
PhoneHome=Phone (Home)
Country=Country

Thats it. You can go to webapp/index.html#/employees and click on any list item to be redirected to corresponding employees details. Check also
what happens when you directly navigate to the following files:
webapp/index.html#/employees/3
webapp/index.html #/employees/33
Previous: Step 6: Navigate to Routes with Hard-Coded Patterns
Next: Step 8: Navigate with Flip Transition
1.3.4.8 Step 8: Navigate with Flip Transition

In this step, we want to illustrate how to navigate to a page with a custom transition animation. Both forward and backward navigation will use the flip
transition but with a different direction. We will create a simple link on the Employee view that triggers a flip navigation to a page that displays the resume
data of a certain employee. Pressing the Back button will navigate back to the Employee view with a reversed flip transition.
Preview
Figure 1: Employee Details page with Flip to Resume link
Figure 2: Resume page with multiple tabs

Figure 3: Not Found page for resume
Coding
webapp/view/employee/Employee.view.xml
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.Employee"
xmlns="sap.m"
<Page
id="employeePage"
title="{i18n>EmployeeDetailsOf} {FirstName} {LastName}"
<content>
<Panel
id="employeePanel"
width="auto"
class="sapUiResponsiveMargin sapUiNoContentPadding">
<headerToolbar>
<Toolbar>
<Title text="{i18n>EmployeeIDColon} {EmployeeID}" level="H2"/>
<ToolbarSpacer />
<Link text="{i18n>FlipToResume}" tooltip="{i18n>FlipToResume.tooltip}" press="onShowResume" />

</Toolbar>
</headerToolbar>
<content>
...
</content>
</Panel>
</content>
</Page>
</mvc:View>
First we add the Flip to Resume link to the Employee Details view to trigger the navigation to the resume of the employee that is currently displayed.
webapp/controller/employee/Employee.controller.js
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.employee.Employee", {
...
}
}
...
},
onShowResume : function (oEvent) {
var oCtx = this.getView().getElementBinding().getBoundContext();
this.getRouter().navTo("employeeResume", {
employeeId : oCtx.getProperty("EmployeeID")
});
}
});
});
Then we change the Employee.controller.js file by adding the press handler onShowResume for the Flip to Resume link. The handler simply
navigates to a new route employeeResume and fills the mandatory parameter employeeId with the property EmployeeID from the views bound context.
The route employeeResume is not available yet, so we will have to add it to our routing configuration.
{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"bypassed": {
}
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"
}, {
}, {
"name": "employee",

}, {
"pattern": "employees/{employeeId}/resume",
"name": "employeeResume",
"target": "employeeResume"
}],
"targets": {
"home": {
"viewName": "Home",
"viewLevel" : 1
},
"notFound": {
},
"employees": {
"viewLevel" : 2
},
"employee": {
"viewName": "employee.Employee",
"viewLevel" : 3
},
"employeeResume": {
"viewName": "employee.Resume",
"viewLevel" : 4,
"transition": "flip"
}
}
}
}
}
In the routing configuration, we add a new route employeeResume which references a target with the same name. The routes pattern expects an
{employeeId} as a mandatory parameter and ends with the static string /resume.
The target employeeResume references the view employee.Resume that we are about to create. The targets viewLevel is 4; compared to the employee
target this is one level lower again. To configure a flip navigation, we simply set the transition of our target to flip. Together with the correct viewLevel
configuration this will trigger the correct forward and backward flip navigation whenever the target is displayed.
Note
Possible values for the transition parameter are:
slide (default)
flip
show
fade
You can also implement your own transitions and add it to a control that extends sap.m.NavContainer (for example, sap.m.App or
sap.m.SplitApp). For more information, see the API Reference for NavContainer.
webapp/view/employee/Resume.view.xml (New)
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.Resume"
xmlns="sap.m"
<Page
title="{i18n>ResumeOf} {FirstName} {LastName}"
id="employeeResumePage"
<content>
<IconTabBar
id="iconTabBar"
class="sapUiResponsiveContentPadding"
binding="{Resume}">
<items>
<IconTabFilter id="infoTab" text="{i18n>Info}" key="Info">
<Text text="{Information}" />
</IconTabFilter>
<IconTabFilter id="projectsTab" text="{i18n>Projects}" key="Projects">
<mvc:XMLView viewName="sap.ui.demo.nav.view.employee.ResumeProjects"></mvc:XMLView>
</IconTabFilter>
<IconTabFilter id="hobbiesTab" text="{i18n>Hobbies}" key="Hobbies">
<Text text="{Hobbies}" />
</IconTabFilter>

<IconTabFilter id="notesTab" text="{i18n>Notes}" key="Notes">
<Text text="{Notes}" />
</IconTabFilter>
</items>
</IconTabBar>
</content>
</Page>
</mvc:View>
Create a file Resume.view.xml inside the webapp/view/employee folder. The view uses an IconTabBar to display the resume data. Therefore, its
binding attribute is set to {Resume}.
In the IconTabBar we display four tabs. Three of them simply use a Text control to display the data from the service. The Projects tab uses a nested
XML view to display the projects of the employee. SAPUI5 takes care of loading the XML view automatically when the user navigates to the Resume page.
webapp/controller/employee/Resume.controller.js (New)
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.employee.Resume", {
oRouter.getRoute("employeeResume").attachMatched(this._onRouteMatched, this);
},
var oArgs, oView;
oView.bindElement({
events : {
},
}
}
});
},
}
}
});
});
Create a file Resumee.controller.js in the webapp/controller/employee folder. In this controller, we make sure to bind the view to the correct
employee whenever the employeeResume route has matched. We have already used this approach in the previous step so you should be able to recognize
the building blocks in the code above. Again, in case the user cannot be found we display the notFound target.
webapp/view/employee/ResumeProjects.view.xml (New)
<Text text="{Projects}" />
</mvc:View>
Create a file ResumeProjects.view.xml in the webapp/view/employee folder. This view does not have a controller as we dont need it. It just displays
a Text control with the projects text of the selected employee. It illustrates that using nested views works just fine in combination with navigation and routing
in SAPUI5.
Note
For more complex applications, the performance is significantly increased if parts of the UI are only loaded when the user is actively selecting it. In this
example, the view is always loaded even though the user never decided to display the project information. In the next steps, we will extend the UI so that
the content is loaded lazy by SAPUI5 only when the filter item is clicked. The back-end service will fetch the data only on request and the UI will only
have to be updated with the selected data instead of loading all data.
...
ResumeOf=Resume of
Info=Info
Projects=Projects
Hobbies=Hobbies

Notes=Notes
FlipToResume=Flip to Resume
FlipToResume.tooltip=See the resume of this employee
You can go to webapp/index.html#/employees/3 and click on the Flip to Resume link to be redirected with a nice flip transition to the employees
resume. The back navigation uses a reverse flip navigation to get back to the Employee Details page. You can also directly navigate to
webapp/index.html#/employees/3/resume or webapp/index.html#/employees/33/resume to see what happens.
Previous: Step 7: Navigate to Routes with Mandatory Parameters
Next: Step 9: Allow Bookmarkable Tabs with Optional Query Parameters
1.3.4.9 Step 9: Allow Bookmarkable Tabs with Optional Query

Parameters
The resume view contains four tabs as we have seen in the previous steps. However, when the user navigates to the resume page, only the first tab is
displayed initially. Navigating directly to a specific tab or bookmarking a tab is not yet supported in our current app.
In this step, we implement a bookmarking feature by enabling deep linking to tabs with optional query parameters. A deep link is basically a link that directly
references a deeper structure and parameters of the app in the URL. It is often bookmarked or shared to have a convenient entry point into the app for a
certain task or action. The selected tab should be reflected in the URL but the tab can also be omitted, for example, when we initially navigate to the resume
page.
Preview
Figure 1: Deep link to allow bookmarkable tabs
Coding
{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"bypassed": {
}
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"
}, {

}, {
"name": "employee",
}, {
"pattern": "employees/{employeeId}/resume:?query:",
}],
"targets": {
...
}
}
}
}
Up until now, you could only navigate to an employees resume with the deep link webapp/index.html#/employees/3/resume. This will always select
the first tab as implemented by the IconTabBar control. In order to open the page directly with a specific tab selected and to make the tabs bookmarkable,
we add the query parameter to the URL pattern.
This allows URLs like webapp/index.html#/employees/3/resume?tab=Projects where the query parameter defines which tab shall be displayed.
We change the pattern of the employeeResume route to employees/{employeeId}/resume:?query:. The new part :?query: allows to pass on
queries with any parameters, for example, the hash /#/employees/3/resume?tab=Projects or /#/employees/3/resume?
tab=Projects&action=edit matches the pattern and can be processed in the matched event.
The :?query: parameter starts and ends with :; this means that it is optional. If you want to make it mandatory, you can use the {?query} syntax
(everything in between {} is considered as being mandatory).
webapp/view/employee/Resume.view.xml
<mvc:View
xmlns="sap.m"
<Page
<content>
<IconTabBar
id="iconTabBar"
binding="{Resume}"
select="onTabSelect"
selectedKey="{view>/selectedTabKey}">
<items>
</IconTabFilter>
</IconTabFilter>
</IconTabFilter>
</IconTabFilter>
</items>
</IconTabBar>
</content>
</Page>
</mvc:View>
To update the currently selected tab in the URL we listen to the select event of the IconTabBar by setting select="onTabSelect" in the resume view.
The selectedKey is bound to a view model. This allows to easily change the selectedKey according to the selected tab in the URL.
webapp/controller/employee/Resume.controller.js
sap.ui.define([
"sap/ui/demo/nav/controller/BaseController",

], function (BaseController, JSONModel) {
"use strict";
var _aValidTabKeys = ["Info", "Projects", "Hobbies", "Notes"];
this.getView().setModel(new JSONModel(), "view");
oRouter.getRoute("employeeResume").attachMatched(this._onRouteMatched, this);
},
var oArgs, oView, oQuery;
oView.bindElement({
events : {
},
}
}
});
oQuery = oArgs["?query"];
if (oQuery && _aValidTabKeys.indexOf(oQuery.tab) > -1){
oView.getModel("view").setProperty("/selectedTabKey", oQuery.tab);
} else {
// the default query param should be visible at all time
employeeId : oArgs.employeeId,
query: {
tab : _aValidTabKeys[0]
}
},true /*no history*/);
}
},
}
},
onTabSelect : function (oEvent){
var oCtx = this.getView().getBindingContext();
employeeId : oCtx.getProperty("EmployeeID"),
query: {
tab : oEvent.getParameter("selectedKey")
}
}, true /*without history*/);
}
});
});
When a tab is selected manually, its select handler is called. Therefore, lets first have a look at the onTabSelect event handler that is added at the end of
the resume controller. It detects the selectedKey of the tab and navigates to the employeeResume route to update the URL in the address bar.
Additionally to the mandatory parameter employeeId, we pass on a custom query object with a parameter tab and fill it with the selectedKey value that
we receive from the select event of the IconTabBar. By passing on true as the third argument we replace the current history to make sure that manually
clicked tabs wont be added to the browser history.
A dependency to sap/ui/model/json/JSONModel is added to the controller. Now, we modify the onInit function to instantiate a JSONModel and use it
as the view model. _aValidTabKeys is added to the controller. We want to make sure that only valid tabs can be selected. Therefore, the array
_aValidTabKeys contains all allowed tab keys that we can check against to validate the tab parameter from the URL later. The keys are equal to the keys
of our IconTabFilters in the resume view.
In the _onRouteMatched event handler, we add the oQuery variable to store a reference to the query object from the router. This allows a more comfortable
access to the query object.
In case a query object is passed on and the tab parameter has a valid value, we display the specific tab by updating the property /selectedTabKey in the
view model. As the selectedKey property of the IconTabBar is bound to {view>/selectedTabKey} the corresponding tab is selected.
The else case is called when either no or an invalid tab parameter is specified. We navigate to the Info tab to make sure that the tab parameter is reflected
in the URL at all times. The actual requirements of your app might differ, feel free to change it accordingly...
From now on our tabs are bookmarkable. Try to access the following (deep) links directly:
webapp/index.html#/employees/3/resume
webapp/index.html#/employees/3/resume?tab=Info

webapp/index.html#/employees/3/resume?tab=Projects
webapp/index.html#/employees/3/resume?tab=Hobbies
webapp/index.html#/employees/3/resume?tab=Notes
webapp/index.html#/employees/3/resume?tab=SomethingInvalid
When you click on any tab you will see that the hash in the URL changes immediately, and when you change the hash in the URL parameter manually, you
can see that the UI is also updated accordingly.
Previous: Step 8: Navigate with Flip Transition
Next: Step 10: Implement Lazy Loading
Step 10: Implement Lazy Loading

In the previous steps, we have implemented a Resume view that uses tabs to display data. The complete content of the tabs is loaded once, no matter
which tab is currently displayed. We can increase the performance of our app by avoiding to load content that is not visible. Therefore, we implement a lazy
loading feature that only loads the view and data when requested by the user.
Preview
Figure 1: Tabs with lazy loading
Coding
webapp/view/employee/Resume.view.xml
<mvc:View

xmlns="sap.m"
<Page
<content>
<IconTabBar
id="iconTabBar"
binding="{Resume}"
select="onTabSelect"
selectedKey="{view>/selectedTabKey}">
<items>
</IconTabFilter>
</IconTabFilter>

</IconTabFilter>

</IconTabFilter>
</items>
</IconTabBar>
</content>
</Page>
</mvc:View>
To illustrate lazy loading, we implement that the content is loaded only when the user selects the corresponding tab for two of our tabs from the IconTabBar:
Hobbies and Notes . The IconTabFilter controls each have a hard-coded ID so that we can address them later in our routing configuration. In real use
cases, you would do this for tabs that contain a lot of content or trigger expensive service calls to a back-end service.
In the resume view we remove the content of the Hobbies and Notes tabs as we will now fill it dynamically with navigation features.
webapp/view/employee/ResumeHobbies.view.xml (New)
</mvc:View>
Create the file ResumeHobbies.view.xml in the webapp/view/employee folder. Move the content for the tab that was previously in the resume view to
that view. We dont need a controller for this view as there is no additional logic involved. This view will be lazy-loaded and placed into the content of the
Hobbies tab with navigation features.
webapp/view/employee/ResumeNotes.view.xml (New)
</mvc:View>
Create the file ResumeNotes.view.xml in the webapp/view/employee folder similar to the Hobbies view to transform this tab to a separate view as
well.
webapp/controller/employee/Resume.controller.js
sap.ui.define([
], function (BaseController, JSONModel) {
"use strict";
var _aValidTabKeys = ["Info", "Projects", "Hobbies", "Notes"];
...
var oArgs, oView, oQuery;
oView.bindElement({
...
});
oQuery = oArgs["?query"];

if (oQuery && _aValidTabKeys.indexOf(oQuery.tab) > -1){
oView.getModel("view").setProperty("/selectedTabKey", oQuery.tab);
// support lazy loading for the hobbies and notes tab
if (oQuery.tab === "Hobbies" || oQuery.tab === "Notes"){
// the target is either "resumeTabHobbies" or "resumeTabNotes"
this.getRouter().getTargets().display("resumeTab" + oQuery.tab);
}
} else {
// the default query param should be visible at all time
employeeId : oArgs.employeeId,
query: {
tab : _aValidTabKeys[0]
}
},true /*no history*/);
}
},
...
});
});
Now we extend the resume controller a little and add additional logic to the part of the _onRouteMatched function where a new tab has been selected and
validated. In case the selectedKey matches Hobbies or Notes we call this.getRouter().getTargets().display("resumeTab" +
oQuery.tab) to display the corresponding target manually. Here the valid targets are resumeTabHobbies and resumeTabNotes as we have changed the
behavior for these two tabs by creating separate views.
These lines of code make sure that the targets are only loaded when they are needed (lazy loading). But the router does not know the new targets yet, so
lets create them in our routing configuration.
{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"bypassed": {
}
},
"routes": [{
...
}, {
}],
"targets": {
...
"employeeResume": {
"viewName": "employee.Resume",
"viewLevel" : 4,
"transition": "flip"
},
"resumeTabHobbies": {
"parent": "employeeResume",
"viewName": "ResumeHobbies",
"viewId": "thisIsMyCustomIdToBeUsedForResumeHobbies",
"controlId": "hobbiesTab",
"controlAggregation": "content"
},
"resumeTabNotes": {

"viewName": "ResumeNotes",
"controlId": "notesTab",
}
}
}
}
}
We add the resumeTabHobbies and resumeTabNotes targets to the descriptor file with additional fields that override the default configuration as we now
want to display the targets locally inside the IconTabBar control and not as pages of the app.
The resumeTabHobbies target sets the parent property to employeeResume. The parent property expects the name of another target. In our case, this
makes sure that the view from the parent target employeeResume is loaded before the target resumeTabHobbies is displayed. This can be considered as
a view dependency. By setting the controlId and controlAggregation properties the router places the view ResumeHobbies into the content
aggregation of the IconTabFilter control with ID hobbiesTab. We also set a parameter viewId to a custom ID to illustrate how you could overrule a
hard-coded ID inside a view.
Note
Each target can define only one parent with its parent property. This is similar to the SAPUI5 control tree where each control can have only one parent
control (accessed with the method getParent() of sap.ui.base.ManagedObject). The controlId property always references a control inside the
parent view that is specified with the parent target.
Now we add the resumeTabNotes target similar to the Hobbies target. The resumeTabNotes target defines the parent target employeeResume as well,
because they share the same parent view. We place the ResumeNotes view into the content aggregation of the IconTabFilter control with ID
notesTab.
We have now implemented lazy loading for the tabs Hobbies and Notes . These two tabs are now managed by the routing configuration and only loaded
when we click on them the first time.
Try it out yourself: Open the Network tab of your browser's developer tools and click on the tabs of your app. In the network traffic you will see that
ResumeHobbies.view.xml file is only loaded when the Hobbies tab is displayed the first time. The same applies for the Notes tab. Mission
accomplished!
Conventions
Lazy-load content that is not initially displayed to the user
Previous: Step 9: Allow Bookmarkable Tabs with Optional Query Parameters
Next: Step 11: Assign Multiple Targets
1.3.4.11 Step 11: Assign Multiple Targets

In this step, we will add a new button to the home page to illustrate the usage of multiple targets for a route. When the button is pressed, a new page opens
that contains two parts: a header part at the top and a content part. The content part displays a table of employees that can be sorted and searched. We will
use the array notation in the routing configuration to assign multiple targets to a route - a feature that we have not yet introduced.
Preview
Figure 1: New button Show Employee Overview

Figure 2: Employee Overview with search field
Figure 3: Sort options for the Employee Overview
Coding
<mvc:View
xmlns="sap.m"
<content>
<Button id="displayNotFoundBtn" text="{i18n>DisplayNotFound}" press="onDisplayNotFound" class="sapUiTinyMarginEnd"/>
<Button id="employeeListBtn" text="{i18n>ShowEmployeeList}" press="onNavToEmployees" class="sapUiTinyMarginEnd"/>
<Button id="employeeOverviewBtn" text="{i18n>ShowEmployeeOverview}" press="onNavToEmployeeOverview" class="sapUiTinyMarginEnd"/
</content>
</Page>
</mvc:View>
First we add a new button to the Home view and add an event handler for the press event.
sap.ui.define([
"use strict";
...
onNavToEmployees : function (oEvent){
this.getRouter().navTo("employeeList");
},

onNavToEmployeeOverview : function (oEvent) {
this.getRouter().navTo("employeeOverview");
}
});
});
As you know already from the previous steps, we add the press event handler onNavToEmployeeOverview. It navigates to the route
employeeOverview which does not exist yet, so lets create it.
{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"bypassed": {
}
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"
}, {
}, {
"pattern": "employees/overview",
"name": "employeeOverview",
"target": ["employeeOverviewTop", "employeeOverviewContent"]
}, {
"name": "employee",
}, {
}],
"targets": {
...
"resumeTabNotes": {
"viewName": "ResumeNotes",
"controlId": "notesTab",
},
"employeeOverview": {
"viewPath": "sap.ui.demo.nav.view.employee.overview",
"viewName": "EmployeeOverview",
"viewLevel" : 2
},
"employeeOverviewTop": {
"parent": "employeeOverview",
"viewName": "EmployeeOverviewTop",
"controlId": "EmployeeOverviewParent",
},
"employeeOverviewContent": {
"parent": "employeeOverview",

"viewName": "EmployeeOverviewContent",
"controlId": "EmployeeOverviewParent",
}
}
}
}
}
We extend our current routing configuration with a new route employeeOverview. Note that this route has to be configured before the employee route, else
the employee route would be matched with a hash like /#/employees/overview. The new route employeeOverview references two targets at the
same time with an array notation: employeeOverviewTop and employeeOverviewContent. As you can see here, a route can reference an arbitrary
number of targets that will be displayed when the route is matched.
Both targets employeeOverviewTop and employeeOverviewContent reference the target employeeOverview as their parent target because we want
to place them both inside the parent. Please also note that we also introduce a new layer overview in the viewPath property.
Note
The order of the routing configuration matters here, because the router stops matching additional routes when the first match is found. You can override
this behavior if you set parameter greedy to true on the route. Then the route will always be matched when the pattern matches the current URL, even if
another route has been matched before. The greedy option comes from the underlying Crossroads.js library, a popular routing library. A common use
case for using greedy is configuring targets without views and then listening for route-matched events.
Now we create both targets employeeOverviewTop and employeeOverviewContent as well as their parent target employeeOverview. On the parent
target we set viewLevel to 2 to ensure a correct transition animation. In the targets, we also configure where the corresponding views of the children shall be
displayed by setting the parameters controlId and controlAggregation to a control ID of a sap.ui.layout.HorizontalLayout that we are about
to create in a new view. You should be familiar with this configuration from the last step.
The router makes sure that the parent view is loaded in addition to the target view when a corresponding route has been matched and the targets are
displayed. The referenced views are displayed automatically at the configured place in the parents view, in our case in the content aggregation of the page
control. We have mentioned three different views that we still need to add to the app to make the configuration work:
EmployeeOverview
EmployeeOverviewTop
EmployeeOverviewContent
webapp/view/employee/overview/EmployeeOverview.view.xml (New)
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.overview.EmployeeOverview"
xmlns="sap.m"
xmlns:l="sap.ui.layout">
<Page id="EmployeeOverviewParent" title="{i18n>EmployeeOverview}"
<content>

</content>
</Page>
</mvc:View>
First we create the parent view by creating the folder overview under webapp/view/employee and placing the file EmployeeOverview.view.xml into
that folder. This view contains a Page control that is referenced from the targets in our manifest.json descriptor file. The content aggregation of the page
will be filled by the router with the top and content part when the corresponding route has been hit.
webapp/controller/employee/overview/EmployeeOverview.controller.js (New)
sap.ui.define([
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.employee.overview.EmployeeOverview", {
});
});
The controller does not contain any logic yet, but we will add back navigation features here in the next steps.
webapp/view/employee/overview/EmployeeOverviewTop.view.xml (New)
<mvc:View xmlns="sap.m" xmlns:mvc="sap.ui.core.mvc" class="sapUiMediumMarginBottom">
<Title text="{i18n>EmployeeOverviewTop}" />
</mvc:View>
Create the file EmployeeOverviewTop.view.xml and place it in the webapp/view/employee/overview folder. This view displays a static text for
illustration purposes. Change it according to your own requirements. We dont need a controller for this view

webapp/view/employee/overview/EmployeeOverviewContent.view.xml (New)
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.overview.EmployeeOverviewContent"
xmlns="sap.m"
<Table id="employeesTable"
items="{/Employees}">
<headerToolbar>
<Toolbar>
<Title text="{i18n>Employees}" level="H2"/>
<ToolbarSpacer />
<SearchField id="searchField" search="onSearchEmployeesTable" width="50%"/>
<Button icon="sap-icon://sort" press="onSortButtonPressed" />
</Toolbar>
</headerToolbar>
<columns>
<Column id="employeeIDCol"><Text text="{i18n>EmployeeID}"/></Column>
<Column id="firstNameCol" demandPopin="true"><Text text="{i18n>FirstName}"/></Column>
<Column id="lastNameCol" demandPopin="true"><Text text="{i18n>LastName}"/></Column>
<Column id="addressCol" minScreenWidth="Tablet" demandPopin="true"><Text text="{i18n>Address}"/></Column>
<Column id="cityCol" minScreenWidth="Tablet" demandPopin="true"><Text text="{i18n>City}"/></Column>
<Column id="regionCol" minScreenWidth="Tablet" demandPopin="true"><Text text="{i18n>Region}"/></Column>
<Column id="postalCodeCol" minScreenWidth="Tablet" demandPopin="true"><Text text="{i18n>PostalCode}"/></Column>
<Column id="countryCol" minScreenWidth="Tablet" demandPopin="true"><Text text="{i18n>Country}"/></Column>
<Column id="homePhoneCol" minScreenWidth="Tablet" demandPopin="true" hAlign="Right"><Text text="{i18n>Phone}"/></Column>
</columns>
<items>
<ColumnListItem>
<cells>
<Text text="{EmployeeID}"/>
<Text text="{FirstName}"/>
<Text text="{LastName}"/>
<Text text="{Address}"/>
<Text text="{City}"/>
<Text text="{Region}"/>
<Text text="{PostalCode}"/>
<Text text="{Country}"/>
<Text text="{HomePhone}"/>
</cells>
</ColumnListItem>
</items>
</Table>
</mvc:View>
Create the file EmployeeOverviewContent.view.xml in the webapp/view/employee/overview folder. This view displays a responsive table with several
columns containing employee data like Employee ID , First Name , Last Name and so on. In the headerToolbar, we add the SearchField and a
Button. The SearchField in the header area allows to search in the table. The Button next to it opens a dialog to adjust the sorting of the table.
webapp/controller/employee/overview/EmployeeOverviewContent.controller.js (New)
sap.ui.define([
"sap/ui/model/FilterOperator",
"sap/ui/model/Sorter"
], function (BaseController, Filter, FilterOperator, Sorter) {
"use strict";
return BaseController.extend("sap.ui.demo.nav.controller.employee.overview.EmployeeOverviewContent", {
this._oTable = this.getView().byId("employeesTable");
this._oVSD = null;
this._sSortField = null;
this._bSortDescending = false;
this._aValidSortFields = ["EmployeeID", "FirstName", "LastName"];
this._sSearchQuery = null;
this._initViewSettingsDialog();
},
onSortButtonPressed : function (oEvent) {
this._oVSD.open();
},
onSearchEmployeesTable : function (oEvent) {
var sQuery = oEvent.getSource().getValue();
this._applySearchFilter( oEvent.getSource().getValue() );
},
_initViewSettingsDialog : function () {
this._oVSD = new sap.m.ViewSettingsDialog("vsd", {

confirm: function (oEvent) {
var oSortItem = oEvent.getParameter("sortItem");
this._applySorter(oSortItem.getKey(), oEvent.getParameter("sortDescending"));
}.bind(this)
});
// init sorting (with simple sorters as custom data for all fields)
this._oVSD.addSortItem(new sap.m.ViewSettingsItem({
key: "EmployeeID",
text: "Employee ID",
selected: true // we do this because our MockData is sorted anyway by EmployeeID
}));
key: "FirstName",
text: "First Name",
selected: false
}));
key: "LastName",
text: "Last Name",
selected: false
}));
},
_applySearchFilter : function (sSearchQuery) {
var aFilters, oFilter, oBinding;
// first check if we already have this search value
if (this._sSearchQuery === sSearchQuery) {
return;
}
this._sSearchQuery = sSearchQuery;
this.byId("searchField").setValue(sSearchQuery);
// add filters for search
aFilters = [];
if (sSearchQuery && sSearchQuery.length > 0) {
aFilters.push(new Filter("FirstName", FilterOperator.Contains, sSearchQuery));
aFilters.push(new Filter("LastName", FilterOperator.Contains, sSearchQuery));
oFilter = new Filter({ filters: aFilters, and: false }); // OR filter
} else {
oFilter = null;
}
// update list binding
oBinding = this._oTable.getBinding("items");
oBinding.filter(oFilter, "Application");
},
/**
* Applies sorting on our table control.
* @param {string} sSortField the name of the field used for sorting
* @param {string} sortDescending true or false as a string or boolean value to specify a descending sorting
* @private
*/
_applySorter : function (sSortField, sortDescending){
var bSortDescending, oBinding, oSorter;
// only continue if we have a valid sort field
if (sSortField && this._aValidSortFields.indexOf(sSortField) > -1) {
// convert the sort order to a boolean value
if (typeof sortDescending === "string") {
bSortDescending = sortDescending === "true";
} else if (typeof sortDescending === "boolean") {
bSortDescending = sortDescending;
} else {
bSortDescending = false;
}
// sort only if the sorter has changed
if (this._sSortField && this._sSortField === sSortField && this._bSortDescending === bSortDescending) {
return;
}
this._sSortField = sSortField;
this._bSortDescending = bSortDescending;
oSorter = new Sorter(sSortField, bSortDescending);
// sync with View Settings Dialog
this._syncViewSettingsDialogSorter(sSortField, bSortDescending);
oBinding = this._oTable.getBinding("items");
oBinding.sort(oSorter);
}
},
_syncViewSettingsDialogSorter : function (sSortField, bSortDescending) {
// the possible keys are: "EmployeeID" | "FirstName" | "LastName"
// Note: no input validation is implemented here
this._oVSD.setSelectedSortItem(sSortField);

this._oVSD.setSortDescending(bSortDescending);
}
});
});
Finally create the controller for the Employee Overview page in the webapp/controller/employee/overview folder. It basically sets up a
ViewSettingsDialog to sort and filter the table of employees and implements event handlers for the search field and for the sorting of the table.
There is nothing special about this implementation. If you are interested in how to set up a table with sorting and filtering you can check the corresponding
steps of the Walkthrough tutorial or the examples in the Explored app. We will mainly make use of the UI and the functionality for showing additional
navigation and routing features. Therefore, we suggest copying the code and trying it out.
Open webapp/index.html#/employees/overview and check the new views. As you can see, the three views are wired together automatically by the
router based on our configuration in the descriptor. In the top area of the page, you see a static text and below you see the table filled with data from our test
service. The whole routing functionality that we see in this example is implemented by referencing two targets from one route.
Of course, you can also search the table and change the sorting. When the sorting dialog opens, it creates a block layer so that the back button and other
controls cannot be accessed. However, you can still use the back button of the browser. As you can see, the dialog is closed automatically by the router
before navigating.
Note
The default behavior of the sap.m router is that all dialogs are closed when the hash changes (i.e. when calling navTo, display or pressing the back
button of the browser). You can change this default behavior by calling getTargetHandler().setCloseDialogs(false) on the router or on the
Targets object.
However, we have one problem yet to solve: the search and table ordering are not bookmarkable. Fortunately, we have additional navigation features at hand
and you will see how this works in the next steps
...
EmployeeOverview=Employee Overview
ShowEmployeeOverview=Show Employee Overview
EmployeeOverviewTop=Employee Overview Top
Region=Region
EmployeeID=Employee ID
Phone=Phone
Employees=Employees
Add the new texts to the properties file.
Previous: Step 10: Implement Lazy Loading
Next: Step 12: Make a Search Bookmarkable
1.3.4.12 Step 12: Make a Search Bookmarkable

In this step we will make the search bookmarkable. This allows users to search for employees in the Employees table and they can bookmark their search
query or share the URL.
Preview
Figure 1: Search and sorting bookmarkable
Coding

{
"_version": "1.1.0",
"sap.app": {
...
},
"sap.ui": {
...
},
"sap.ui5": {
...
"routing": {
"config": {
"viewType": "XML",
"controlId": "app",
"bypassed": {
}
},
"routes": [{
"pattern": "",
"name": "appHome",
"target": "home"
}, {
}, {
"pattern": "employees/overview:?query:",
"name": "employeeOverview",
"target": ["employeeOverviewTop", "employeeOverviewContent"]
}, {
"name": "employee",
}, {
}],
"targets": {
...
}
}
}
}
In order to make the search bookmarkable we have to think about how the pattern of the corresponding route should match the bookmark. We decide to allow
/#/employees/overview?search=mySearchQueryString in order to bookmark a search. Therefore, we simply extend our routing configuration a little.
We add the optional :?query: parameter to the route employeeOverview. We keep in mind that we want to use search as the URL parameter for the
search term that was entered in the search field.
webapp/controller/employee/overview/EmployeeOverviewContent.controller.js
sap.ui.define([
"use strict";
this._oTable = this.getView().byId("employeesTable");
this._oVSD = null;
this._sSortField = null;
this._bSortDescending = false;
this._aValidSortFields = ["EmployeeID", "FirstName", "LastName"];
this._sSearchQuery = null;
this._oRouterArgs = null;

this._initViewSettingsDialog();
// make the search bookmarkable
oRouter.getRoute("employeeOverview").attachMatched(this._onRouteMatched, this);
},
// save the current query state
this._oRouterArgs = oEvent.getParameter("arguments");
this._oRouterArgs.query = this._oRouterArgs["?query"] || {};
delete this._oRouterArgs["?query"];
if (this._oRouterArgs.query) {
// search/filter via URL hash
this._applySearchFilter(this._oRouterArgs.query.search);
}
},
this._oVSD.open();
},
onSearchEmployeesTable : function (oEvent) {
// update the hash with the current search term
this._oRouterArgs.query.search = oEvent.getSource().getValue();
oRouter.navTo("employeeOverview",this._oRouterArgs, true /*no history*/);
},
...
});
});
Now we handle the optional query parameter from the employeeOverview route in our EmployeeOverviewContent controller. First we change the
onInit function by adding an event listener for the matched event of the employeeOverview route. Then we buffer the current router arguments as
received from the event. If a query is available, the result from oEvent.getParameter("arguments") will contain a ?query property with an object of all
URL parameters specified, otherwise it is undefined. For an easier access and to always initialize the query, we save the ?query object containing all query
parameters to this._oRouterArgs.query and delete the duplicate at this._oRouterArgs["?query"]. If we have a search term query at the
search key we continue and call this._applySearchFilter(this._oRouterArgs.query.search) to trigger a search based on the search query
parameter from the URL.
Storing the arguments objects internally in the controller is important, because we will use the current arguments when calling navTo() in the search event
handler onSearchEmployeesTable and pass on the arguments with the updated search term. We keep the URL and the UI in sync by navigating to the
current target again with the current value of the search field from the events source. The search value is stored in this._oRouterArgs.query.search
together with the other query parameters and it is passed directly to the router again
Thats it, now our search is bookmarkable and reflected in the URL. Try to access the following pages in your browser:
webapp/index.html#/employees/overview
webapp/index.html#/employees/overview?search=
webapp/index.html#/employees/overview?search=an
When you change the value in the search field, you see that the hash updates accordingly.
Previous: Step 11: Assign Multiple Targets
Next: Step 13: Make Table Sorting Bookmarkable
1.3.4.13 Step 13: Make Table Sorting Bookmarkable

In this step, we will create a button at the top of the table which will change the sorting of the table. When the current sorting state of the table is changed, the
sorting state will be reflected in the URL. This illustrates how to make the table sorting bookmarkable.
Preview
Figure 1: Bookmarkable search and sorting

Coding
sap.ui.define([
"use strict";
...
},
// sorting via URL hash
this._applySorter(this._oRouterArgs.query.sortField, this._oRouterArgs.query.sortDescending);
}
},
...
this._oRouterArgs.query.sortField = oSortItem.getKey();
this._oRouterArgs.query.sortDescending = oEvent.getParameter("sortDescending");
oRouter.navTo("employeeOverview",this._oRouterArgs, true /*without history*/);
}.bind(this)
});
...
},
...
});
});
We enhance the EmployeeOverviewContent controller further to add support for bookmarking the tables sorting options. We expect two query parameters
sortField and sortDescending from the URL for configuring the sorting of the table. In the matched handler of the route employeeOverview we add an
additional call to this._applySorter(this._oRouterArgs.query.sortField, this._oRouterArgs.query.sortDescending). This triggers
the sorting action based on the two query parameters sortField and sortDescending from the URL.
Next we change the confirm event handlers of our ViewSettingsDialog. The confirm handler updates the current router arguments with the
parameters from the event accordingly. Then we call oRouter.navTo("employeeOverview",this._oRouterArgs, true) with the updated router
arguments to persist the new sorting parameters in the URL. Both the previous arguments (i.e. search) and the new arguments for the sorting will then be
handled by the matched event handler for the employeeOverview route.
Congratulations! Even the sorting options of the table can now be bookmarked. Try to access the following pages:
webapp/index.html#/employees/overview?sortField=EmployeeID&sortDescending=true
webapp/index.html#/employees/overview?search=an&sortField=EmployeeID&sortDescending=true
When changing the tables sorting options, you will see that the hash updates accordingly.
Previous: Step 12: Make a Search Bookmarkable
Next: Step 14: Make Dialogs Bookmarkable
1.3.4.14 Step 14: Make Dialogs Bookmarkable

In this step, we want to allow bookmarking of the dialog box that is opened when the user clicks the Sort button. The dialog should automatically open when
the URL contains the query parameter showDialog.
Preview

Figure 1: Bookmark for a dialog
Coding
/controller/employee/overview/EmployeeOverviewContent.controller.js
sap.ui.define([
"use strict";
...
},
// sorting via URL hash
this._applySorter(this._oRouterArgs.query.sortField, this._oRouterArgs.query.sortDescending);
// show dialog via URL hash
if (!!this._oRouterArgs.query.showDialog) {
this._oVSD.open();
// make sure the dialog does not get closed automatically
oEvent.preventDefault();
}
}
},
this._oRouterArgs.query.showDialog = 1;
oRouter.navTo("employeeOverview",this._oRouterArgs);
},
...
this._oRouterArgs.query.sortField = oSortItem.getKey();
this._oRouterArgs.query.sortDescending = oEvent.getParameter("sortDescending");
delete this._oRouterArgs.query.showDialog;

}.bind(this),
cancel : function (oEvent){
delete this._oRouterArgs.query.showDialog;
}.bind(this)
});
...
},
...
});
});
Once again we will update the EmployeeOverviewContent controller to add support for the bookmarking of our sorting dialog. We decide to choose a query
parameter showDialog that controls if the dialog is opened directly when we navigate to the page with a deep link. Therefore, we extend the matched event
handler for the employeeOverview route. If the query parameter showDialog is set to 1 (note the implicit conversion to a Boolean type for the check) we
open the dialog. We only have to make sure that the dialog does not get closed again by the router as this behavior is the default when navigating. Therefore,
we call oEvent.preventDefault() to tell the router that we want to keep the dialog open.
Next we change the press handler of the sort button. In the onSortButtonPressed function we set this._oRouterArgs.query.showDialog = 1
and call navTo() to let the router do the job instead of directly opening the dialog. Finally, we delete this._oRouterArgs.query.showDialog before
calling navTo() in the confirm and cancel event handlers of the ViewSettingsDialog. This is important to make sure that the dialog does not open
again by the matched handler.
We are now done with this step. Try to access the following pages:
webapp/index.html#/employees/overview?showDialog=1
webapp/index.html#/employees/overview?search=an&sortField=EmployeeID&sortDescending=true&showDialog=1
As you can see, the dialog opens automatically if the parameter showDialog=1 is added to the URL. Thats exactly what we wanted.
Previous: Step 13: Make Table Sorting Bookmarkable
Next: Step 15: Reuse an Existing Route
1.3.4.15 Step 15: Reuse an Existing Route

The Employees table displays employee data. However, the resumes of the employees are not accessible from this view yet. We could create a new route
and a new view to visualize the resume again, but we could also simply reuse an existing route to cross-link the resume of a certain employee. In this step, we
will add a feature that allows users to directly navigate to the resume of a certain employee. We will reuse the Resume page that we have created in an
earlier step. This example illustrates that there can be multiple navigation paths that direct to the same page.
Preview
Figure 1: Navigation to an existing route from a table item
Coding
webapp/view/employee/overview/EmployeeOverviewContent.view.xml
<mvc:View
controllerName="sap.ui.demo.nav.controller.employee.overview.EmployeeOverviewContent"
xmlns="sap.m"
<Table id="employeesTable"
items="{/Employees}"
itemPress="onItemPressed">
<headerToolbar>

...
</headerToolbar>
<columns>
...
</columns>
<items>
<ColumnListItem type="Active">
<cells>
...
</cells>
</ColumnListItem>
</items>
</Table>
</mvc:View>
In the EmployeeOverviewContent view we register an event handler for the itemPress event and set the type attribute of the ColumnListItem to
Active so that we can choose an item and trigger the navigation.
sap.ui.define([
"use strict";
...
_syncViewSettingsDialogSorter : function (sSortField, bSortDescending) {
// the possible keys are: "EmployeeID" | "FirstName" | "LastName"
// Note: no input validation is implemented here
this._oVSD.setSelectedSortItem(sSortField);
this._oVSD.setSortDescending(bSortDescending);
},
onItemPressed : function (oEvent) {
var oItem, oCtx, oRouter;
oItem = oEvent.getParameter("listItem");
oCtx = oItem.getBindingContext();
this.getRouter().navTo("employeeResume",{
employeeId : oCtx.getProperty("EmployeeID"),
query : {
tab : "Info"
}
});
}
});
});
Next we add the itemPress handler onItemPressed to the EmployeeOverviewContent controller. It reads from the binding context which item has
been chosen and navigates to the employeeResume route. We have already added this route and the corresponding target in a previous step and can now
reuse it. From now on it is possible to navigate to the employeeResume route from our employee table as well as from the employee detail page created in
an earlier step (the route name is employee).
Previous: Step 14: Make Dialogs Bookmarkable
Next: Step 16: Handle Invalid Hashes by Listening to Bypassed Events
1.3.4.16 Step 16: Handle Invalid Hashes by Listening to Bypassed

Events
So far we have created many useful routes in our app. In the very early steps we have also made sure that a Not Found page is displayed in case the app
was called with an invalid hash. Now, we proceed further and track invalid hashes to be able to detect and correct any invalid links or add new URL patterns
that are often requested but not found. Therefore, we simply listen to the bypassed events
Preview

Figure 1: Console output for invalid hashes when listening to bypassed events
Coding
sap.ui.define([
"use strict";
oRouter.attachBypassed(function (oEvent) {
var sHash = oEvent.getParameter("hash");
// do something here, i.e. send logging data to the back end for analysis
// telling what resource the user tried to access...
jQuery.sap.log.info("Sorry, but the hash '" + sHash + "' is invalid.", "The resource was not found.");
});
}
});
});
All we need to do is listen to the bypassed event on the router. If the bypassed event is triggered, we simply get the current hash and log a message. In an
actual app this is probably the right place to add some application analysis features, i.e. sending analytical logs to the back end for later evaluation and
processing. This could be used to improve the app, for example, to find out why the user called the app with an invalid hash.
Note
We have chosen to place this piece of code into the App controller because this is a global feature of the app. However, you could also place it anywhere
else, for example in the NotFound controller file or in a helper module related to analysis.
Now try to access webapp/index.html#/thisIsInvalid while you have your browser console open. As you can see, there is a message that issues a
faulty hash. Furthermore, our NotFound page is displayed.
Previous: Step 15: Reuse an Existing Route
Next: Step 17: Listen to Matched Events of Any Route
1.3.4.17 Step 17: Listen to Matched Events of Any Route

In the previous step, we have listened for bypassed events to detect possible technical issues with our app. In this step, we want to improve the analysis use
case even more by listening to any matched event of the route. We could use this information to measure how the app is used and how frequently the pages
are called. Many Web analytic tools track page hits this way. The collected information can be used, for example to improve our app and its usability.
Preview

Figure 1: Console output for routes matched by listening to routeMatched events
Coding
sap.ui.define([
"use strict";
oRouter.attachBypassed(function (oEvent) {
var sHash = oEvent.getParameter("hash");
// do something here, i.e. send logging data to the back end for analysis
// telling what resource the user tried to access...
jQuery.sap.log.info("Sorry, but the hash '" + sHash + "' is invalid.", "The resource was not found.");
});
oRouter.attachRouteMatched(function (oEvent){
var sRouteName = oEvent.getParameter("name");
// do something, i.e. send usage statistics to back end
// in order to improve our app and the user experience (Build-Measure-Learn cycle)
jQuery.sap.log.info("User accessed route " + sRouteName + ", timestamp = " + new Date().getTime());
});
}
});
});
We extend the App controller again and listen to the routeMatched event. The routeMatched event is thrown for any route that matches to our route
configuration in the descriptor file. In the event handler, we determine the name of the matched route from the event parameters and log it together with a time
stamp. In an actual app, the information could be sent to a back-end system or an analytics server to find out more about the usage of your app.
Now you can access, for example, webapp/index.html#/employees while you have the console of the browser open. As you can see, there is a
message logged for each navigation step that you do within the app.
Previous: Step 16: Handle Invalid Hashes by Listening to Bypassed Events
Next: Summary
1.3.4.18 Summary
You have now completed the tutorial "Navigation and Routing" for SAPUI5.
You should now be familiar with all major features and APIs for navigation and routing in SAPUI5.
Previous: Step 17: Listen to Matched Events of Any Route
1.3.5 Testing
1.3.5 Testing
In this tutorial we will test application functionality with the testing tools that are delivered with SAPUI5. At different steps of this tutorial you will write tests
using QUnit, OPA5, and the mock server. Additionally, you will learn about testing strategies, Test Driven Development (TDD), and much more.
For the application features that we add, we focus on writing clean and testable code with the goal of having good test coverage and a high quality app. We will
create a simple full screen app that we will extend with more tests and features throughout the tutorial.
Imagine the following situation: You and your development team take over a bulletin board prototype that will be shipped as a product soon. A bulletin board
typically consists of functionality to browse posts and add own offers to the board. However, the prototype only covers a minimum set of features and tests so
far.
With this very minimalistic app as a starting point, we have a good foundation and we can inspect the most important testing functionality. Furthermore, we
want to implement new features for the app that were requested by the product team using Test Driven Development and best practices for writing testable
code and testing SAPUI5 apps.
So why do we do all this? Obviously, writing tests and testable code does not come without effort. Well, we want to ensure the implementation of a high quality
app by having decent test coverage of our application logic. And we check that our code does not break by running the automated tests whenever we change
something or when we upgrade to a newer version of the SAPUI5 framework or other external libraries. Additionally, we can find bugs proactively and do not
need excessive manual testing anymore so the efforts definitely pay off. Also, when we decide to refactor something in the future, we can easily verify that the
features of the app are still working as expected.
There are a lot more reasons and many small details that we will address throughout this tutorial. You can work yourself through the steps by applying the
code deltas individually or by downloading the samples for each step from the explored app and playing around with it.
Preview
Prerequisites
In addition to the prerequisites that are presupposed for all our tutorials (see Prerequisites), you should also be familiar with the basics of JavaScript unit
testing with QUnit. Have a look at the official QUnit documentation to make yourself familiar with basic testing knowledge. Steps 27 to 29 of the Walkthrough
tutorial also cover the test setup in an app that is used throughout this tutorial.
Tip
You don't have to do all tutorial steps sequentially, you can also jump directly to any step you want. Just download the code from the previous step, and
start there.
You can view and download the files for all steps in the Explored app in the demo kit under Testing Apps . Copy the code to your workspace and make
sure that the application runs by calling the webapp/test/test.html file. Depending on your development environment you might have to adjust
resource paths and configuration entries.
Troubleshooting
1. Step 1: Overview and Testing Strategy

In this step, we will take a look at the prototype that is handed over to us and define the test strategy for our app. The prototype already contains the
infrastructure for unit and integration testing and a minimum set of tests and features.
2. Step 2: A First Unit Test
In this step we will analyze the unit testing infrastructure and write a first unit test.
3. Step 3: Adding the Price Formatter
We will now take care of the implementation of the price formatter and make sure that the tests we wrote in the previous step run successfully.
4. Step 4: Testing a New Module
In the first unit test we have just extended the formatters module with a new function. Now we will write a unit test that will test the functionality of an
entirely new module.

5. Step 5: Adding a Flag Button
Now that we have implemented the conversion tests, we add the corresponding functionality and show the button to flag a post in the app. The design
team has specified that the flag feature should be implemented with a toggle button that has a flag icon.
6. Step 6: A First OPA Test
A bulletin board may contain many posts. We expect to have a high data load once it is officially released. Then, there might be performance issues and
long loading times if we display all entries at the same time. Therefore we will introduce a feature that limits the initial display to 20 items. The user can
then click on a more button to view more items. As with the unit test, we start by writing an integration test for this feature and then add the application
functionality later.
7. Step 7: Changing the Table to a Growing Table
Lets switch back to developing and add the missing feature for the test we implemented in the previous step. We will simply change the table to a
growing table as this is a basic feature of the table. This will display a trigger at the end of the table that the user can click on to display more items.
8. Step 8: Testing Navigation
So far, we have a list of posts on the home page of the app. But typically, a post comes with more details that should be displayed on a separate detail
page. We call it the post page because it displays details of a post. In this step we will introduce a new journey to test the post page. We write tests that
trigger typical navigation events with OPA. Testing navigation greatly helps in reducing manual testing efforts as it covers a lot of testing paths. It is
good practice to cover every view of your application with at least one test, since OPA will check if an exception is thrown. In this way you can detect
critical errors very fast.
9. Step 9: Adding the Post Page
Now that we have covered all kinds of tests for navigation, we introduce our Post page that shows details of a post in the bulletin board. To achieve
this, we have to introduce a new view/controller pair and adjust the routing of the application.
10. Step 10: Test Suite and Automated Testing
In this step, we will step back from our tests and application features that we have implemented so far and add another important piece of test code: The
test suite page. A test suite can execute multiple tests and collect the results. This comes in handy for automatic tools in a continuous integration
process.
11. Step 11: Testing User Interaction
In this step we want to write a test that simulates user interaction with an icon tab bar. We want to change the tab and check if the correct content is
shown.
12. Step 12: Adding Tabs
We want to display statistics for posts, for example, how many times it was viewed. To achieve this, we implement an icon tab bar with an Info tab and
a Statistics tab. The existing content should be placed on the Info tab and the view count on the Statistics tab.
13. Step 13: Writing a Short Date Formatter Using TDD
It's now time to improve the content of the Info tab. We want to see the Posted At date in a formatted way. Based on the age of the post, we either
display the time, a textural representation of the day, or the date only.
14. Step 14: Adding the Date Formatter
Our formatter does its job, but it is not yet used. In this step we will use it.
15. Summary
You have now completed the Testing tutorial.
Related Information
Testing and Performance Measurement
QUnit Home Page
1.3.5.1 Step 1: Overview and Testing Strategy

In this step, we will take a look at the prototype that is handed over to us and define the test strategy for our app. The prototype already contains the
infrastructure for unit and integration testing and a minimum set of tests and features.
Preview

Figure 1: The prototype app
Coding
To set up your project for this tutorial, download the files for Step 1 from the Explored app in the Demo Kit under Testing - Step 1 . Copy the code to your
workspace and make sure that the application runs by calling the webapp/test/mockServer.html file.
Depending on your development environment you might have to adjust resource paths and configuration entries. The project structure and the files coming with
this tutorial are explained in detail in the Walkthrough tutorial.
You should have the same files as displayed in the following figure:
Figure 2: Folder structure with downloaded files

The Initial App
With the downloaded coding, you have been handed over the bulletin board prototype that is set up according to the SAPUI5 best practices and provides the
following common features of an SAPUI5 app. If you have gone through the Walkthrough tutorial, you should be familiar with most of the source code in this
step. Additional features of the app are:
Entry Page
In this tutorial we will often switch between manually testing application features and running the automated tests. The webapp/test/test.html file
provides a list of entry points for the app so that you do not have to enter the URLs manually. From this page you can open the app with mock data, run
the unit tests, run the integration tests, or run the apps test suite that will be added later in the tutorial. Note that in a productive scenario we would have
an additional entry point that calls the app with a real service. As we do not (yet) have a real service for our prototype but operate on mock data we
simply left this one out.
Home Page
The home page of our bulletin board app is the webapp/test/mockServer.html file. On this page, we initialize SAPUI5, start the mock server, and
instantiate our app component. It only consists of a single view that displays a list of posts from a bulletin board with several attributes in a table.
Note
We do not yet have a real service for the bulletin board prototype so run the app with mock data and this test page throughout the tutorial. The mock
server helps in mimicking a real service and it processes requests with a small delay as a real service would do. This is perfect for realistic
application testing and also helpful for local development tests. It is also a good practice to put all test pages in the test folder of the app, so that
they are clearly separated from the productive coding.
Data
In the webapp/localService/ folder, you can find the metadata and the mock data for the app. The metadata.xml file is used by the mock server
to simulate real back-end service calls in the app. It describes our OData service and can be replaced later by a real service. The service we use has
just one OData entity:
Post
A post consists of typical properties like Title , Description , and Price . Each post is assigned to a Category and a Contact . The entity can
be identified with its ID property: PostID. The corresponding EntitySet is Posts. The actual test data containing several mocked posts is
located in the webapp/test/service/posts.json file.
Testing Functionality
The team that created the first prototype already took care of the basic test setup. Everything required for application testing is shipped with SAPUI5
and can simply be used within the app. The testing infrastructure is set up in the test folder that is located in the webapp folder of the app:
Mock Server
The mock server is set up in the webapp/localService/mockserver.js file. It loads the metadata and the mock data in the same folder.
Using the mock server allows us to easily run the app and show realistic data for testing, even without network connection and without the need of
having a remote server for our application data.
There is a configurable delay for each request that is processed by the mock server that allows mimicking a slow back-end server.
Unit Tests
All unit tests are located in the webapp/test/unit folder and can be started by calling the unitTests.qunit.html file in the same folder.
Initially, there are only a few tests for model instantiation and formatters that cover basic functionality in the prototype. We will explain more details
about the unit test setup later.
Integration Tests
Integration tests are written in OPA5 a tool for integration testing that is included in SAPUI5 and can be found in the
webapp/test/integration folder. You can start all OPA5 tests by calling the opaTests.qunit.html file in the same folder. OPA5 tests
are organized in test journeys, and there is already a worklist journey included that checks if the table of posts is displayed properly. We will
explain more details about the integration test setup later.
Other quality-related features of the app
The app is set up according to best practices and already contains many helpful features. The most important ones are named here.
Separation of concerns (MVC)
All artifacts are located in either the model, view, or controller folder of the app. The apps component and its descriptor is configuring which
of those MVC artifacts to load. the configuration is controlling the navigation flow of the app.
Separation of productive and non-productive code
All non-productive code is located in the test subfolder. This includes the unit and integration tests, and the test page to call the app with mock
data. All productive code is located in the webapp folder. This clearly separates the test artifacts from the application coding and makes it easy to
remove all test-related artifacts before deploying the app for productive use.
Busy handling
As a best practice, users should always get instant feedback when triggering actions and navigating in the app. The app already includes
functionality to display a busy indication when data is loaded or actions are triggered. To simulate a slow backend and show the behavior of the
app the mock server is configured with a delay of one second for each request.
Now we have a running prototype that we can further extend with additional tests and features. Make sure the app is running by calling the test page, the unit
tests, and the integration tests from the entry page webapp/test/test.html. The app should display a list of bulletin board posts as seen in the
screenshot above and the tests should run without errors.
Test Strategy
Lets first take a look at best practices for testing apps written in SAPUI5. JavaScript is a dynamic programming language and only some issues can be
detected by static code check tools and manual testing. Automated tests that execute the code regularly are beneficial for good quality and development
productivity - especially when you're developing in short development cycles.
We expect our prototype to be released and shipped as a product soon, so we need a solid testing strategy. Fortunately the prototype team has already
thought ahead and prepared a unit and integration testing infrastructure that is included in the app. This is a really good starting point for further enhancements
of the app.
The mock server is also set up and allows us to test the app with local test data instead of a real back-end service. We can use the mock data for writing
reliable integration tests that do not depend on another system which might be unavailable when the tests are run.

Note
If you start developing an app from scratch, you should always consider testing from the very beginning of the software life cycle. Nobody wants to write
tests for undocumented code and make assumptions about the logic. It will pay off many times to think about code checks, unit and integration testing and
a solid testing strategy from the very start.
Before you start implementing your first test, you should think about how to test the different aspects of your application. The image below shows the testing
tools along the agile testing pyramid.
Figure 3: Testing pyramid
When we think about application testing, we want to automate as many testing steps as possible. When we immediately write a test for all the features that we
implement then we can greatly reduce manual testing efforts that are time consuming and cumbersome. Whenever we change something later, we can simply
run the existing tests and see if the functionality is still working as expected.
The two testing tools that are included in SAPUI5 are QUnit for unit testing and OPA5 for integration testing. The foundation for our testing pyramid are the unit
tests and they should validate the most important logic of our app. On top, we can write integration tests for more interaction-related functionality like
interacting with UI elements of the app.
There might still be things that are hard to test with these client-side testing frameworks. Certain features might require a more sophisticated system test, like
a screenshot comparison that can be implemented with additional testing frameworks. And of course, you should also schedule manual tests (for example,
browser, performance, or security tests) to make sure that the app is behaving as expected.
Note
In this tutorial we will focus on writing clean unit and integration tests for apps. They build the foundation and are crucial for good application quality. We
will also outline how to write testable code. Not all implementation patterns can be tested easily. But when writing the test code together with the
implementation code as in this tutorial it is a natural result.
Conventions
Write unit tests in QUnit for more logic-related functionality
Write integration tests in OPA5 for user interaction
Separate productive and non-productive code within the app (webapp, test folder)
Provide a local test page that triggers the app in test mode with mock data (test/mockServer.html)
Parent topic: Testing
Next: Step 2: A First Unit Test
Related Information
App Templates: Kick Start Your App Development
Worklist Template
Testing and Performance Measurement
Unit Testing with QUnit
Integration Testing with One Page Acceptance Tests (OPA5)
Mock Server
1.3.5.2 Step 2: A First Unit Test

In this step we will analyze the unit testing infrastructure and write a first unit test.

The product team requested a feature to highlight the price with colors depending on the amount. This can be done using the standard semantic colors that are
defined for states like Success , Warning , or Error .
The price values can be mapped to semantic states as follows:
price < 50: Status is green ( Success )
price >= 50 and price < 250: Status is normal ( None )
price >= 250 and price < 2000: Status is orange ( Warning )
price >= 2000: Status is red ( Error )
As we use Test Driven Development (TDD) we define the test case first, before we actually implement the feature. So we will now start by implementing a test
for the Price State feature. Naturally the test will fail until the feature is implemented in the next step.
Note
Test Driven Development (TDD) is a software development model that relies on a very short development cycle. When using TDD a developer first writes a
failing automatic test case to describe the behavior of a new feature or functionality. As soon as the test fails (due to the still missing implementation) the
role of the developer switches to the implementation. The code is added to make the test run successful and then the cycle starts over again.
There might also be iterations where just the implementation or testing code is refactored to make it more elegant. TDD reduces complexity while
maintaining high test coverage of the application coding at the same time.
Preview
Figure 1: The unit test will initially fail as the implementation is not provided yet
Coding
You can view and download all files in the Explored app in the Demo Kit under Testing Apps - Step 2 .
Unit Test Setup

All unit tests are located in the webapp/test/unit folder and can be started manually by calling the unitTests.qunit.html file in the same folder or
the entry page. This HTML page is a QUnit runner that calls all unit tests of the app and displays the test results in a readable format.
Note
Some testrunners like Karma do not require an HTML page to invoke the tests but work with configuration files instead. They can directly invoke the
allTests.js file and log the test results in their own format. Therefore we make sure that the allTests.js file does not contain any UI output and just
calls the various test cases of the app.

Figure 2: Unit test infrastructure in the application
Lets take a closer look at the unitTests.qunit.html file. The application root is stored in the webapp folder two levels above. In the bootstrap tag of
the HTML page we define two namespaces to refer to the app and the unit tests. The namespace of the unit tests points to the current folder as all test
artifacts are located below the current folder:
sap.ui.demo.bulletinboard: "../../"
test.unit: "./"
The namespace abstraction allows us to refer to all application and testing parts without having to use the full path. Furthermore, all unit tests are put in a
similar folder structure and get the same name as the artifact that is tested. For example, the tests for the file webapp/model/formatter.js are located
in the webapp/test/unit/model/formatters.js folder. For more details on the unit test setup please have a look at the coding of the prototype.
Coding
You can view and download all files in the Explored app in the Demo Kit under Testing Apps- Step 2 .
webapp/model/formatter.js
sap.ui.define([
"sap/m/Text"
], function (Text) {
"use strict";
return {
numberUnit: function (sValue) {

},
priceState: function () {
}
};
});
First we think about the feature that we want to implement. We want to introduce a new state for the price, and its value should depend on certain price ranges.
SAPUI5 controls typically have semantic states like Success , Warning , or Error . We will need this formatter function to convert the numeric price value
from the model to a state value for the control. But without caring too much about the actual implementation of this formatter we just add an empty function
priceState to the formatter file for now and focus on the unit tests first.
webapp/test/unit/model/formatter.js
sap.ui.require(
[
"sap/ui/demo/bulletinboard/model/formatter"
],
function (formatter) {
"use strict";
QUnit.module("Number unit");

QUnit.module("Price State");
function priceStateTestCase(oOptions) {
// Act
var sState = formatter.priceState(oOptions.price);
// Assert
oOptions.assert.strictEqual(sState, oOptions.expected, "The price state was correct");
}
QUnit.test("Should format the products with a price lower than 50 to Success", function (assert) {
priceStateTestCase.call(this, {
assert: assert,
price: 42,

expected: "Success"
});
});
QUnit.test("Should format the products with a price of 50 to Normal", function (assert) {
assert: assert,
price: 50,
expected: "None"
});
});
QUnit.test("Should format the products with a price between 50 and 250 to Normal", function (assert) {
assert: assert,
price: 112,
expected: "None"
});
});
QUnit.test("Should format the products with a price between 250 and 2000 to Warning", function (assert) {
assert: assert,
price: 798,
expected: "Warning"
});
});
QUnit.test("Should format the products with a price higher than 2000 to Error", function (assert) {
assert: assert,
price: 2001,
expected: "Error"
});
});
}
);
Now we write tests that call the function we have just defined and check for the correct result when passing in various arguments.
By writing these tests, we actually implement the following specification in our tests that was defined by the product team.
price < 50: Status is green ( Success )
price >= 50 and price < 250: Status is normal ( None )
price >= 250 and price < 2000: Status is orange ( Warning )
price >= 2000: Status is red ( Error )
Whenever we run the tests, we will implicitly check that the feature is still working as it was designed. To keep it simple, we should only write a minimum set
of tests that cover the most important cases, but also including edge cases like the value 50 or unexpected values.
Lets have a look at the implementation of the unit tests now: We add our unit tests to the webapp/test/unit/model/formatter.js file. The path below
the app and the test folder is similar so it can easily associate the test with the tested functionality. There are already formatter functions for the number unit
conversion defined in the code - you can have a quick look before we add our own tests.
We add a new QUnit module for our price state tests after the number unit conversion tests. We could write a test checking the result of the formatter for each
of these cases but we do not want to repeat ourselves (DRY) neither in the tests nor in the application coding so we create a reuse function called
priceStateTestCase. In this function, we call the formatter with the arguments provided as oOptions and make a strictEqual assertion for the
expected parameter.
Note
There must be at least one assertion per QUnit test. If the actual value matches the expected value then the test is successful. However, if there are more
assertions in a test case and a subsequent assertion fails, the whole test fails with the error message of the failed assertion.
There are also other types of assertions, for example the ok assertion that does not check the type. For more details, have a look at the official QUnit
documentation.
The assert object a special object injected by QUnit is passed on as a reference to the function. QUnit is loaded once for the whole unit testing part of the
app.
Note
The main page for calling the unit tests is webapp/test/unit/unitTests.qunit.html. In this file we load the QUnit runtime and an allTests.js
file that loads and directly executes all files with unit tests. The other content of this file is just HTML for displaying the QUnit test result page.
And now for the actual test cases: Whenever we want to start a new test we call QUnit.test with a test description and a callback function containing the
test logic as an argument. The callback is invoked with a special assert object that is maintained by QUnit. We can simply call assertions as we saw above.
Inside each test we simply call our reuse function with different parameters for the price and the expected state that reflect our specification above. With five
tests we can check the most important cases for our price state converter. There are four tests for the four different states and one edge case test with the
value 50, that makes sure that the correct state is chosen.
Thats it, you just wrote your first unit test. When you call the webapp/test/unit/unitTests.qunit.html file in your browser, you can see that the first
module for the number unit formatter is still green but our price state tests are red and failing. The error message tells us that the result of the empty formatter
function is not as expected.
TDD methodology tells us to do the implementation as soon as the test fails and to come back to testing as soon as the tests are successful again. You run
the unit tests after each code change, and you're done when the test does not fail anymore. We now switch to the implementation part and define the details of
the formatter function in the next step.

Conventions
Write unit tests for testing the logical correctness of your features
Previous: Step 1: Overview and Testing Strategy
Next: Step 3: Adding the Price Formatter
Related Information
QUnit Testing Fundamentals
QUnit Home Page
1.3.5.3 Step 3: Adding the Price Formatter

We will now take care of the implementation of the price formatter and make sure that the tests we wrote in the previous step run successfully.
If the tests are passed, we can be sure that the formatter is formally correct but it is still not visible in the app. So additionally, we will add the formatter to the
UI to be able to verify and check that the price is shown properly.
Preview
Figure 1: The price is now formatted with a semantic color
Coding
You can view and download all files in the Explored app in the Demo Kit under Testing - Step 3 .
webapp/model/formatter.js
sap.ui.define([
"sap/m/Text"
], function (Text) {
"use strict";
return {
numberUnit: function (sValue) {

},
/**
* Defines a value state based on the price
*
* @public
* @param {number} iPrice the price of a post
* @returns {string} sValue the state for the price
*/
priceState: function (iPrice) {

if (iPrice < 50) {
return "Success";
} else if (iPrice >= 50 && iPrice < 250) {
return "None";
} else if (iPrice >= 250 && iPrice < 2000) {
return "Warning";
} else {
return "Error";
}
}
};
});
We change the empty formatter function that we have added in the last step and add the implementation details to it. If the implementation matches the
specification embedded in our tests we are done with implementing the formatter.
The input for the formatter is the price value from the model and the result is the state as a string value. The actual implementation logic is quite simple and
returns a semantic state value based on the price as we have seen already in the test. There are four cases that are reflected in the if/else statements
inside the formatter.
You can now run the file webapp/test/unit/unitTests.qunit.html and check if the unit tests run successfully. You should see your new test cases
on the result page. If the overall result is successful then we have successfully implemented our first feature.
webapp/view/Worklist.view.xml

<ColumnListItem vAlign="Middle">
<cells>

<ObjectNumber
number="{
path: 'Price',
formatter: '.formatter.numberUnit'
}"
state="{
path: 'Price',
formatter: '.formatter.priceState'
}"
unit="{Currency}"/>
</cells>
</ColumnListItem>

We still have to apply the changes to our UI so that we can actually see the formatted price in the app. Unit tests are typically testing the logic independent of
the user interface. That is why the tests are running successfully even though we did not adapt the UI yet.
In our worklist view we simply add a state attribute to the ObjectNumber control in the columns aggregation. We define the same data binding path as for
the number, but we use our new formatter function to determine the proper state. If you now run the webapp/test/mockServer.html file, you can see that
some of the product prices are listed in green, black, orange, and red depending on their price.
Previous: Step 2: A First Unit Test
Next: Step 4: Testing a New Module

Saphelp Ui

Uploaded by

Copyright:

Available Formats

Saphelp Ui

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Saphelp Ui

Uploaded by

Copyright:

Available Formats

SAPUI5: UI Development Toolkit for HTML5

PDF download from SAP Help Portal:

Created on January 26, 2017

PUBLIC Page 1 of 244

PUBLIC Page 2 of 244

PUBLIC Page 3 of 244

PUBLIC Page 4 of 244

Check the SAPUI5 playlist in the SAP Technology YouTube

What's New in SAPUI5

PUBLIC Page 5 of 244

What's New in SAPUI5 1.38

jQuery Upgraded to Version 2.2.3

For more information see OData V4 Model.

PUBLIC Page 6 of 244

Regular Mode Split Mode

PUBLIC Page 7 of 244

PUBLIC Page 8 of 244

sap.m.NotificationListItem: The control has two improvements:

sap.ui.comp (Smart Controls):

PUBLIC Page 9 of 244

PUBLIC Page 10 of 244

Column Chart Stacked Column Chart Vertical Bullet Chart

For more information on these charts, see Analytic Cards

What's New in SAPUI5 1.36

PUBLIC Page 12 of 244

PUBLIC Page 13 of 244

PUBLIC Page 14 of 244

Browser and Platform Support

What's New in SAPUI5 1.34

Security Vulnerability Fixed

New and Improved Features

PUBLIC Page 15 of 244

PUBLIC Page 16 of 244

PUBLIC Page 17 of 244

For more information, see sap.suite.ui.microchart .

PUBLIC Page 18 of 244

PUBLIC Page 19 of 244

PUBLIC Page 20 of 244

PUBLIC Page 21 of 244

Documentation and Demo Kit Improvements

PUBLIC Page 22 of 244

What's New in SAPUI5 1.32

For more information, see UI5 Inspector.

PUBLIC Page 24 of 244

This control is responsive and works seamlessly on mobile devices.

PUBLIC Page 25 of 244

PUBLIC Page 26 of 244

sap.m.ComboBox: Improved rendering performance by internally using sap.m.SelectList instead of sap.m.List.

PUBLIC Page 27 of 244

Documentation and Demo Kit Improvements

PUBLIC Page 28 of 244

What's New in SAPUI5 1.30

Demo Kit Improvements

PUBLIC Page 29 of 244

Figure 2: Quick View

PUBLIC Page 30 of 244

PUBLIC Page 31 of 244

Infrastructure on Application Server for ABAP

jQuery Unit Testing Library QUnit Upgraded

SAP Smart Business