WebProgrammingUsingUI5 Day2

Web Programming using
SAP UI5
Bogdan MIHAI
Research Scientist, Performance and Insight Optimization
September 30th, October 2nd, 4th, 7th and 9th, 2013 Internal
Web Programming using SAP UI5
From zero to hero in just 5 days
Bogdan MIHAI (bogdan-eugen.mihai@sap.com)
Performance and Insight Optimization
September 30th, October 2nd, 4th, 7th and 9th, 2013
Agenda – part 1
Day 1 – September 30th

 Introduction
 HTML
 HTTP
 JavaScript
Day 2 – October 2nd

 Quiz
 Introduction
 Internet Architecture
 Internet Communication
 SAP UI5 Overview
 SAP UI5 Programming
 SAP UI5 Controls API
© 2013 SAP AG. All rights reserved. Internal 3

Agenda – part 2
Day 3 – October 4th

 Quiz
 Introduction
 MVC Concepts
 Fragments
 Localization
 JSON Model Binding
 OData Model Binding
 Quiz
 Introduction
 Charts
 Using external JavaScript libraries
 Modularization and Resource Handling
 Styling and Theming
Agenda – part 3

 Quiz
 Custom Controls
 Security Concepts
 DEMO: Building A Sample Web Application From Scratch
 Final Quiz
 Feedback

Web Programming using
SAP UI5
Day 2 – October 2nd
1. Introduction
2. Internet Architecture
2. Internet Architecture and Communication
Data Independence in Relational Databases
What users see
Tables and links
Files on disk
Each level is independent of the levels

bellow!
Data Independence
Logical Independence: The ability to change the logical schema without changing
the external schema or application programs:
 Can add new fields, new tables, without changing views
Physical Independence: The ability to change the physical schema without

changing the logical schema:
 Storage space can change
 Type of some data can change for optimization reasons
Lesson: Try your best to keep the VIEW (what the user sees) independent of the
MODEL (domain knowledge)

Significance of Tiers
N-tier architecture have the same components

 Presentation
 Business Logic
 Data
N-tier architecture try to separate the components into different tiers or layers
 Tier – physical separation
 Layer – logical separation

1-Tier Architecture
All 3 layers are on the same machine

 All code and processing are kept on a single physical machine
Presentation, Logic, Data layers are tightly connected

 Scalability – Single processor means hard to increase volume of processing
 Portability – Moving to a new machine may mean rewriting everything
 Maintenance – Changing one layer requires changing other layers

2-Tier Architecture
Database runs on Server

 Separated from the client
 Easy to switch to a different database (vendor, version)
Presentation and logic layers still tightly connected

 Heavy load on server
 Potential congestion on network
 Presentation still tied to business logic

3-Tier Architecture
Each layer can potentially run on a different machine
Presentation, logic and data layers disconnected

A Typical 3-Tier Architecture
Architecture Principles
 Client-server architecture
 Each tier (Presentation, Logic and Data)

should be independent and should not
expose dependencies related to internal
implementation
 Unconnected tiers should not communicate
 Any change in platform or technology of one

tier should not affect the other tiers.

Presentation Layer
 Provides a user interface
 Handles the interaction with the user
 Sometimes called the GUI, client view or

front-end
 Should not contain business logic, nor data

access code
 Should perform preliminary data validation

(to better handle server load)

Logic Layer
 The set of rules for processing information
 Can accommodate multiple users/sessions
 Sometimes called middleware or back-end
 Should not contain presentation or data

access code

Data Layer
 The physical storage layer for data
persistence
 Manages access to the database or file

system
 Sometimes called back-end
 Should not contain presentation or business

logic code

The 3-Tier Architecture for Web Applications

Presentation Layer
 Static or dynamically generated content rendered by the browser (front-end)
 Usually developed in scripting languages (JavaScript, ActionScript) and HTML
Logic Layer
 A dynamic content processing and generation level based on a high-level
application server
 Usually developed in high-level languages like Java, Microsoft .NET, C++ etc.
Data Layer
• A database, relational or NOSQL, comprising both data sets and the database
management system
• Usually developed in SQL

3-Tier Architecture Advantages

Independence of layers
 Easier to maintain
 Components are reusable
 Faster development by employing division of work
– Web designers do the presentation layer
– Software engineers do the logic layer
– DB admins do the data model
Biggest drawback: very difficult to have a unitary vision of the application

(not a real disadvantage)

Meanwhile In The Real World…

 1-Tier Architecture – old-legacy, small or specialized desktop application
 2-Tier Architecture – modern desktop applications, small web and mobile applications
 3-Tier Architecture – anything modern or new, the INTERNET
The biggest 2 advantages of the 3-Tier Architecture:

 One can have multiple front-ends (Presentation tiers) for the same back-end (the other
components)
– A mobile app and a website can use the same application server and database
– Multiple clients can access the same server
 One can replace any tier (or layer) without affecting the others.

Design Problems & Decisions

Construction and testing
• how do we build a web application?
• what technology should we choose?
Re-use
• can we use standard components?
Scalability
• how will our web application cope with large numbers of requests?
Security
• how do we protect against attack, viruses, malicious data access, denial of
service?
Different data views
• user types, individual accounts, data protection
Need for general and reusable solution: Design Patterns

What Is A Design Pattern?
A general and reusable solution to a commonly occurring problem in the design of

software
A template for how to solve a problem that has been used in many different
situations
NOT a finished design
• the pattern must be adapted to the application
• cannot simply translate into code

Origin Of Design Patterns
Architectural concept by Christopher

Alexander (1977/79)
Adapted to OO Programming by Beck

and Cunningham (1987)
Popularity in Computer Science after the

book: “Design Patterns: Elements of Re-
useable Object-oriented software”, 1994.
Erich Gamma, Richard Helm, Ralph
Johnson, John Vlissides
Now widely-used in software engineering

Design Problems
• Need to change the look-and-feel without changing the core/logic
• Need to present data under different contexts (e.g., powerful desktop, web,
mobile device).
• Need to interact with/access data under different contexts (e.g., touch screen on
a mobile device, keyboard on a computer)
• Need to maintain multiple views of the same data (list, thumbnails, detailed, etc.)

Design Solutions
• Separate core functionality from the presentation and control logic that uses this
functionality
• Allow multiple views to share the same data model
• Make supporting multiple clients easier to implement, test, and maintain

The Model View Controller
• Design pattern for graphical systems

that promotes separation between
model and view
• With this pattern the logic required for

data maintenance (database, text file)
is separated from how the data is
viewed (graph, numerical) and how
the data can be interacted with (GUI,
command line)

The MVC Pattern

Model
• manages the behavior and data of the
application domain
• responds to requests for information about
its state (usually from the view)
• follows instructions to change state (usually
from the controller)
View
• renders the model into a form suitable for
interaction, typically a user interface
(multiple views can exist for a single model
for different purposes)
Controller
• receives user input and initiates a response
by making calls on model objects
• accepts input from the user and instructs
the model and viewport to perform actions
based on that input
The MVC Pattern

Model
• Contains domain-specific knowledge
• Records the state of the application
• E.g., what items are in shopping cart
• Often linked to a database
• Independent of view
• One model can link to different views
View
• Presents data to the user
• Allows user interaction
• Does no processing
Controller
• defines how user interface reacts to user
• input (events)
• receives messages from view (where events come from)
• sends messages to model (tells what data to display)

The MVC For Web Applications

Model
• database tables (persistent data)
• session information (current system state data)
• rules governing transactions
View
• (X)HTML
• CSS style sheets
• server-side templates
Controller
• client-side scripting
• http request processing
• business logic/preprocessing

MVC Advantages
Clarity of Design
• model methods give an API for data and state
• eases the design of view and controller
Efficient Modularity
• any of the components can be easily replaced
Multiple Views
• many views can be developed as appropriate
• each uses the same API for the model
Easier to Construct and Maintain
• simple (text-based) views while constructing
• more views and controllers can be added
• stable interfaces ease development
Distributable
• natural fit with a distributed environment

3-Tier Architecture vs. MVC Pattern
Communication
• 3-tier: The presentation layer never communicates directly with the data layer-
only through the logic layer (linear topology)
• MVC: All layers communicate directly (triangle topology)
Usage
• 3-tier: Mainly used in web applications where the client, middleware and data
tiers ran on physically separate platforms
Still, try to use them both!

3. Internet Communication
How do things communicate one to each other in the Internet?
Two major communication strategies

 Dedicated protocols (and dedicated TCP ports)
– Yahoo Messenger uses Yahoo Messenger Protocol (YMP)
– mIRC uses Internet Rely Chat (IRC)
– Pidgin uses Extensible Messaging and Presence Protocol (XMPP)
– World of Warcraft uses a private protocol
– Some “old” applications even use lower-level protocols such as CORBA and RMI
 Web Services - they use the HTTP protocol, thus the name “web”

Dedicated Protocols vs. Web Services
Advantages of dedicated protocols

 Optimized and designed especially for a specified use-case
 Harder do hack, decrypt or modify by any malicious interceptor
 Best used by small Internet applications (chats) or by large-scale online multimedia

applications (games)
Disadvantages of dedicated protocols

 “Harder” to “very hard” to learn and to adopt
 “Very hard” to “impossible” to scale and to upgrade or replace
 May not be universal compatible

Dedicated Protocols vs. Web Services
Advantages of web services

 Highest level of compatibility
 Highest level of abstraction
 Universally available - 99.99% of the computers connected to the Internet have the default
HTTP port open)
 Best used by everything else
Disadvantages of web services

 Difficult to secure
 Exchanged data has a text format (and not binary), thus less optimized

Web Services
Every application programming framework offers a Web Services API
Different underlying technologies

 XML–based: Simple Object Access Protocol (SOAP) – the most popular
 JSON–based
 OData
 others

SOAP vs. JSON
 Well formatted (WSDL)  No format definition
 Better at wrapping-up text because of XML  Possible wrapping issues
 Enterprise acceptance  Less acceptance (but growing)
 Transaction support  No transaction support
 Advanced security  No advanced security
 Bloated and heavy  Lightest (just plane data and nothing else)
 Less performance  Highest performance
 Empowers the RESTful design concept
 Native JavaScript support

Calling Web Services using JavaScript
The XMLHTTPRequest object

 Designed by Microsoft, Adopted by Mozilla and standardized in W3C and the ECMAScript
standard
 Despite its name, it can be used to retrieve any type of data (not just XML, but JSON also,
for example) over other protocols than just HTML (FTP for example)
 It uses HTTP access control for solving same-origin policy issues

Example of a XMLHTTPRequest
try {
var request = new XMLHttpRequest();
request.onreadystatechange = function() {
if (request.readyState === 4) {
if(request.status === 200) {
alert("success");
} else {
alert("server response: " + request.status);
}
}
};
request.open("GET", "http://path.to.my/webservice", true);
request.setRequestHeader("Content-Type","application/json");
request.send(null);
}
catch (e) {
alert("error: " + e.message);
}

The XMLHTTPRequest (XHR) object
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
Some Methods
 void abort()
 void open(DOMString method, DOMString url, optional boolean async, optional DOMString? user,
optional DOMString? Password)
 void send(null/ArrayBuffer/Blob/Document/FormData)
 void setRequestHeader(DOMString header, DOMString value)
Some Properties
 readyState
 responseText
 responseType
 status
 withCredentials

The XMLHTTPRequest (XHR) object – Monitoring Progress
NOTE: One must add the event listeners before calling open() on the XHR!
var xhr = new XMLHttpRequest();
xhr.addEventListener("progress", updateProgress, false);
xhr.addEventListener("load", transferComplete, false);
xhr.addEventListener("error", transferFailed, false);
xhr.addEventListener("abort", transferCanceled, false);
xhr.open();

Asynchronous JavaScript and XML (AJAX)
Question: What is AJAX?

Answer: AJAX stands for Asynchronous JavaScript and XML. In a nutshell, it is the use of the
XMLHttpRequest object to communicate with server-side scripts. It can send as well as
receive information in a variety of formats, including JSON, XML, HTML, and even text files.
AJAX’s most appealing characteristic, however, is its "asynchronous" nature, which means it
can do all of this without having to refresh the page. This lets you update portions of a page
based upon user events.
TL/DR version: set the ”async” flag of the ”open” method to ”true”

4. SAP UI5 Overview
4. SAP UI5 Overview
From the architecture point of view, where does SAP UI5 fit in?
SAP UI5 is a JavaScript framework that handles only the front-end tier (the
Presentation tier), either web or mobile.
 No security concepts – it needs an Application (web) server for this
 No business logic or data access tier – it needs an Application (web) server for this also
 Could be paired with OData for direct database access (experimental features)

4. SAP UI5 Overview
Official Info
 Home page: http://vesapui5.dhcp.wdf.sap.corp:1080/trac/sapui5
o Portal powered by Python, no dogfooding
 The official long name: SAP UI5 Development Toolkit for HTML5
 The official short name: SAP UI5
 The internal name: UI5
 UI5 used to be named "Phoenix", it was changed to SAPUI5 in the summer of 2011 because
the name Phoenix was not suitable to be used publicly.

4. SAP UI5 Overview
Main characteristics
 Business-application orientated
 well-designed API, easy to consume and use
 extensible UI component model, including tooling support
 high performance, SAP product standard compliant
 powerful theming support based on CSS
 provides Ajax capabilities
 based on open standards like OpenAjax, Javascript, CSS, HTML 5, etc.
 using and including the popular jQuery library

4. SAP UI5 Overview
Key Components
 Run time:
– Control libraries (JavaScript, CSS and image files)
– Core (JavaScript files)
– Test suite (HTML, JavaScript files)
 Design time (optional):

– Application development tools in Eclipse
– Control development tools in Eclipse
– Resource handler in Java and ABAP
– Theming generator

4. SAP UI5 Overview
Browser support
SAP UI5 depends on the availability of CSS3 and HTML5

 on Windows OS: IE9+, Firefox, Chrome
 on MAC OS: Safari
 on *nix OS: unofficial support for Chrome-based browsers and Firefox
On mobile:

4. SAP UI5 Overview
Release Plan
Development track
 Identified by a major and an odd minor version number, e.g.
1.5.1
 The versions of this track are released internally and are

not meant to be used in products shipped to customers.
Release track
 Identified by a major and an even minor version number,
e.g. 1.4.1
 The versions of this track are released externally. Only

these versions are allowed to be used in production.

4. SAP UI5 Overview
Extensibility
UI5 allows application developers to
 Include their own JavaScript, HTML and CSS into UI5 based pages
 Include other JavaScript libraries where UI5 is lacking controls or functionality
 Create composite controls from existing UI5 controls
 Write new UI libraries and new controls
 Write plug-ins for the UI5 core

4. SAP UI5 Overview
Documentation and Information UI5 support and question channels

• UI5 Wiki • SAPUI5 Community
• UI5 Mobile Wiki • CSN Component:
• UI5 Tools Wiki • CA-UI5 (UI5 Runtime)
• Demokit • CA-UI5-MOB (UI5 Mobile Lib)
• API Documentation UI5 Tools support and question

channels
• General UI5 Documentation
• SAPUI5 Tools Community
Control and code testing
• CSN Component:
• Test Suite
• CA-UI5-TOL (UI5 Tools)
• SNIPPIX

5. SAP UI5 Programming
SAPUI5 Developer Studio is a set of tools for Eclipse that greatly simplify the
development process for UI5 applications and controls, including:
• Wizards for project and view/controller creation
• Wizards for control development
• Code Completion for UI5 controls
• TeamProvider for NGAP and BSP repositories
• Application preview with an embedded Jetty server
• Proxy-servlet to prevent cross-site-scripting errors
http://vesapui5.dhcp.wdf.sap.corp:1080/trac/sapui5/wiki/Documentation/Tools/
download

Prerequisite: Install the latest Java Development Kit (currently Version 7), if it is not
installed already.
Download and install one of the preconfigured IDEs. If you want to use the SAPUI5
Repository Team Provider you should choose the 32bit version.
It is also possible to setup Eclipse on your own by using one of the available update
sites for Eclipse.
Once Eclipse has been (re)started, the SAPUI5 Eclipse tools should be available.
One way to confirm a successful installation is to check whether you can create a
UI Library Project / SAPUI5 Application Project.
Last but not least: Install a web server, like Apache Tomcat for testing purposes.

Creating a new SAPUI5 Project
 Select "SAPUI5 Application

Project" in the Wizard.
 Click "Next".

 Enter the name of the project.
 Choose between „Desktop“ or „Mobile“ as

the target device for your new project.
 Leave the checkbox "create an initial View"

checked.
 Click "Next".

 Enter the name of the initial view.
 Click "Next".

 The last screen shows you a summary of

the project properties.
 Click "Finish" to create the new project.


First level
Second level
 Third level

First level
Second level
 Third level

First level
Second level
 Third level

Don’t forget about SNIPPIX

 It can run with other (older) versions of UI5

How does SAP UI5 actually work?
UI5 pages always have to start with the bootstrap, to load the UI5 runtime.
Attributes of the script tag are evaluated and used to configure the runtime
 data-sap-ui-libs: the controls libraries to be used, comma-separated
 data-sap-ui-theme: the theme
 There are more attributes: data-sap-ui-language, data-sap-ui-rtl, …

Single Page Application Design

Usually, only one .html file
 The JavaScript is injected into the .html file per request
 No inter-pages navigation
After the bootstrap script tag an "application script" can follow in which the UI5
application is written
• Display your controls in an HTML element called "UI area" by invoking the placeAt method
(there can be multiple UI areas)

jQuery.sap.domById(id)
Useful core functions  Gets any HTML element with id id
sap.ui.getCore()  If there is also a UI5 control with id id, the
 Gets a core instance element returned is the topmost HTML
element of this UI5 control (the UI5
sap.ui.getCore().byId(id) control id is always used there)
 Gets an instance of a UI5 control which was  Similar to document.getElementById but
created with id id gets rid of IE bug which also retrieves
elements with the name of id
 Can be used to access removed controls
(even though the id doesn’t exist in the
jQuery.sap.byId(id)
DOM anymore)
 Returns the jQuery object of the DOM
sap.ui.getCore().applyChanges() element with the specified id
 Carries out and renders the changes for UI5  Similar to jQuery(„#myId“) or
controls immediately, before the runtime $(„#myId“) but handles escaping of
would do it (use carefully!!) dots and adds the hash character

Internal UI5 Rendering
UI5 control tree(s) are only rendered when the HTML page is finished loading
 Only then the UI areas do actually exist in the browser’s DOM
 This corresponds with jQuery’s $(document).ready() function
UI5 largely uses HTML strings to render its controls

 Historically using innerHTML for changing HTML was much faster than changing the DOM
for the same purpose.
Changes to controls (add/remove properties) are not directly carried out

 Onload at initialization (placeAt calls are buffered until then)
 After control event handlers have finished their work
 After application logic has finished changing controls (UI5 registers a timeout)
 When core method applyChanges() is triggered

Must reads:
 JavaScript Coding Guidelines
 Requirements With Respect to SAPUI5 Control Libraries
 Learning From Code-Reviews: Guidelines Re-iterated
 API Reference
 Developer Guide
 Runtime Concepts

6. SAP UI5 Controls API
Six major categories

 Complex
 Dialog
 Layout
 Simple
 UX3
 Value Holders
UX3 Design Philosophy

Complex Controls
 Application Header
 MenuBar, MenuButton, Menu
 Paginator
 Progress Indicator
 Row Repeater
 Table
 Toolbar
 VIZCharts
 View Repeater

Dialog Controls
 Dialog
 Message Box

Layout Controls
 Form
 GridLayout
 HorizontalLayout
 MatrixLayout
 Panel
 Splitter
 VerticalLayout

Simple Controls
 Button
 Image
 Label
 Link

UX3 Controls
 DataSet
 NavigationBar
 NotificationBar
 Shell
 ToolPopup

Value Holder Controls

 AutoComplete
 CheckBox
 ComboBox
 DatePicker
 DropdownBox
 LixtBox
 TextField
 TextArea

Let’s build something!

Thank you
Contact information:
Bogdan MIHAI
Research Scientist, Performance and Insight Optimization
bogdan-eugen.mihai@sap.com
+40 745 394 340

WebProgrammingUsingUI5 Day2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

WebProgrammingUsingUI5 Day2

Transféré par

Droits d'auteur :

Formats disponibles

Web Programming using

Day 1 – September 30th

Day 2 – October 2nd

© 2013 SAP AG. All rights reserved. Internal 3

Day 3 – October 4th

Day 5 – October 9th

© 2013 SAP AG. All rights reserved. Internal 5

Data Independence in Relational Databases

What users see

Tables and links

Each level is independent of the levels

Physical Independence: The ability to change the physical schema without

 Type of some data can change for optimization reasons

© 2013 SAP AG. All rights reserved. Internal 10

N-tier architecture have the same components

 Tier – physical separation

 Layer – logical separation

© 2013 SAP AG. All rights reserved. Internal 11

All 3 layers are on the same machine

Presentation, Logic, Data layers are tightly connected

 Portability – Moving to a new machine may mean rewriting everything

 Maintenance – Changing one layer requires changing other layers

Database runs on Server

 Easy to switch to a different database (vendor, version)

Presentation and logic layers still tightly connected

 Potential congestion on network

 Presentation still tied to business logic

Each layer can potentially run on a different machine

Presentation, logic and data layers disconnected

© 2013 SAP AG. All rights reserved. Internal 14

A Typical 3-Tier Architecture

 Each tier (Presentation, Logic and Data)

 Unconnected tiers should not communicate

 Any change in platform or technology of one

© 2013 SAP AG. All rights reserved. Internal 15

A Typical 3-Tier Architecture

 Handles the interaction with the user

 Sometimes called the GUI, client view or

 Should not contain business logic, nor data

 Should perform preliminary data validation

© 2013 SAP AG. All rights reserved. Internal 16

A Typical 3-Tier Architecture

 Can accommodate multiple users/sessions

 Sometimes called middleware or back-end

 Should not contain presentation or data

© 2013 SAP AG. All rights reserved. Internal 17

A Typical 3-Tier Architecture

 Manages access to the database or file

 Sometimes called back-end

 Should not contain presentation or business

© 2013 SAP AG. All rights reserved. Internal 18

The 3-Tier Architecture for Web Applications

© 2013 SAP AG. All rights reserved. Internal 19

3-Tier Architecture Advantages

Biggest drawback: very difficult to have a unitary vision of the application

© 2013 SAP AG. All rights reserved. Internal 20

Meanwhile In The Real World…

 3-Tier Architecture – anything modern or new, the INTERNET

The biggest 2 advantages of the 3-Tier Architecture:

– Multiple clients can access the same server

© 2013 SAP AG. All rights reserved. Internal 21

Design Problems & Decisions

Need for general and reusable solution: Design Patterns