What is Bootstrap?
The process of loading and initializing SAPUI5 is called bootstrapping. 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_belize 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.
- 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 to
trigger your application logic only after the event has been fired.
What is app Descriptor or
manifest.json used for?
All application-specific
configuration settings are 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 to be hosted in the SAP Fiori launchpad.
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:
o 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.
o Type: Defines what we want to configure, here: an
application
o i18n: Defines the path to the resource bundle file
o Title: Title of the application in handlebars syntax
referenced from the app's resource bundle
o Description: Short description text what the application
does in handlebars syntax referenced from The app's resource bundle
o Application
version: 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:
o Technology: This value specifies the UI technology; in
our case we use SAPUI5
o Device
types: Tells what devices
are supported by the app: desktop, tablet, phone (all true by default)
o Supported
Themes: An array containing a
list of SAP themes supported by the app, for example sap_belize
·
Sap.ui5:- The sap.ui5 namespace
adds SAPUI5-specific configuration parameters that are automatically
processed by SAPUI5. The most important parameters are:
o Root View: The
component will automatically instantiate this view and use it as the root for
this component
o Dependencies: Here we declare the UI libraries used in the
application
o 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.
What are Fragments in sapui5
applications?
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 like "normal" view
content, which means controls inside the fragment will just be included into
the view’s DOM when rendered. 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 reusable controls. The
fragment assets are placed in the core namespace, so we add an xml namespace for it inside the Fragment Definition tag. Because dialogs cannot be specified as
views, we will create an XML fragment containing the dialog.
For e.g.:
What is Shell container in SapUi5?
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 device’s screen size by
introducing a so-called letterbox on desktop screens. Declared in Init method
of index.html file
Before using shell.
After using shell.
What is use of Content Density?
We adjust the content
density based on the user’s 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. 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. To prepare the
content density feature we will also add a helper method getContentDensityClass. This helper method queries the sap.ui.Device API
directly for touch support of the client and returns the CSS ClasssapUiSizeCompact 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.
How FIORI apps adapt to different screen sizes?
By making use of the sap.ui.Device API
and defining a device model . 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 add two new properties EXPANDABLE and EXPANDED
in our app.
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.
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,
What are custom controls?
Custom controls are small
reuseable 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 (metadataand 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 instantiated 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
Explain the concept of Routing and Navigation?
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.
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 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.
What are the types of models used in SAPUI5
applications?
·
JavaScript Object Notation (JSON)
·
Extensible Markup Language (XML)
·
OData
·
Resource model
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.
What
is 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.
What is Aggregation binding?
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.
What is Element Binding?
When 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. To achieve this, we use a form with relatively
bound controls and bind it to the selected entity via element binding.
What is the difference
between standalone apps and apps for Fiori launch pad?
·
If the app runs in FLP it also contains
additional features like Save as Tile or Share in SAP
Jam that depend on FLP at runtime. This app cannot be run standalone,
meaning no index.html file is created but only files for testing the
app in the FLP sandbox.
·
Only standalone apps contain an index.html file that is used to start the app.
What is the use of semantic
page in FIORI apps?
A Semantic Page is an
enhanced sap.m.Page that
contains controls with a semantic meaning and displays them according to the
SAP Fiori Design Guidelines.
Content specified in the sap.m.semantic.SemanticPage#semanticControls aggregations will be automatically positioned in dedicated
sections of the footer or the header of the page, depending on the control's
semantics. For example, a semantic button of type sap.m.semantic.PositiveAction will be positioned in the right side of the footer, and in
logically correct sequence order with respect to any other included semantic
controls.
The full list of what we internally define for semantic content is:
·
Visual properties (e.g. AddAction will be
styled as an icon button)
·
Position in the page (UX guidelines specify
that some buttons should be in the header only, while others are in the footer
or the "share" menu, so we do the correct positioning)
·
Sequence order (UX guidelines define a specific
sequence order of semantic controls with respect to each other)
·
Default localized tooltip for icon-only buttons
·
Overflow behavior (UX quidelines define which
buttons are allowed to go to the overflow of the toolbar when the screen gets
narrower). For icon buttons, we ensure that the text label of the button
appears when the button is in overflow, as specified by UX.
·
Screen reader support (invisible text for
reading the semantic type)
In addition to the predefined semantic controls, the SemanticPage can
host also custom application-provided controls. It preserves most of the API
of sap.m.Page for specifying page content.
What is the use of data
source section in manifest.json file?
An external service is defined in the dataSources section of the sap.app
namespace. In the example shown below, we configure an OData with protocol
version 2.0 and the alias "mainService" in the manifest.json file:
Comments
Post a Comment