L17 Presentation Layer Design

Lecture 17
Presentation Layer Design

Reading
 Patterns
– Model View Controller
– Page Controller
– Front Controller
– Template View
– Application Controller
2

Agenda
 The Web Layer
– Model-View-Controller
 Input controller patterns
– Page Controller
 View patterns
– Template View
3

Play! Framework
 We will be using Play! framework
– Based on MVC

The Challenge
 How to design web applications?
 How to separate user interface from the
business logic?
– User Interface is an HTML string
 How to provide OO design?
– Code reuse
 How can we abstract underlying system
– For example data base
6

Presentation and Web Layers
 Embedded and Desktop clients
 Web Browser is a different type of client
7

The Three Layers
 Presentation
– User’s interface to the system
– User can be another system
– Accepts input, displays views
 Domain
– The Application of the system
– The “Business logic”
– Has the tendency to creep into presentation and data
source
 Data Source
– Connection to the database
9

Web Layer Design
 How to design Web Applications
 Two approaches
– Script based – Code using HTML
– Server Page based – HTML page with code
10
Web Browser Web
Server
HTML/HTTP
Web Application
? ?
DB
Server

Web Applications
 Client is a web Browser
– All interface is HTML with graphics
 Server is configured to map URLs to
applications
– The web application can be script or page
11

Script Based
 Useful when the logic and the flow is important
– Request is not easily mapped to a single page
 Examples
– CGI, ISAPI, Java Servlets
12

Server Page Based
 Useful where there are lots of pages
– Flow is not as important
– Each request can easily be mapped to a page
 Examples
– PHP, JSP, ASP
13

Web Design
 Web Layer must handle the request and the
response
14

API Based
 User Interface is HTML5 or Native App
– Server side is just API
– Information format in XML or Json
HTML5
JavaScript
Web
Server
DB
Controllers
Service Layer
Domain Model
Data Source Layer
Native App
HTTP Request
Json/XML
HTTP Request
Json/XML

Model View Controller
Splits user interface interactions
into three distinct roles
 Separates the user interface from the logic
– Originally from 70s Smalltalk
– Similar to Doc/View in MFC
 MVC considers three roles
– Clear separations of concerns
– Model: The domain layer handles state
– View: Presentation logic
– Controller: Connects the model and the view
17

 How It Works
– Model: The domain layer handles state
– View: Presentation logic
– Controller: Connects the model and the view
18

 Benefits
– Separation of the view from the domain logic in the
model
– This is key in any presentation design
 Importance of MVC
– View and model are different concerns
– View can change, usually the model is the same
– Easy to test the model without the view
 Coupling Dependencies
– View depends on the model, but the model is not
depending on the view 19

 When to Use It
– The value is in the separation of concern
– Separating the model and the view
– As this separation is so fundamental in any software
design, any non-trivial system should use MVC in
some form
20

MVC in Web Design
 Web Applications are request/response based
 Input Controller
– Takes the request
– Examines the input parameters
– Calls the Model
– Decides how to
handle the response
– Sends the control
to the View for
rendering
21

MVC Patterns
– Page Controller
 View patterns
– Template View
– Transform View – Transforms view to some format
– Two Step View – Logical Screen and final UI
23

QUIZ
What design principle is the most important in Model View
Controller?
A) Separation of different concerns
B) All request go the same place
C) Easy to test different components
D) Easy to change the view

QUIZ
What design principle is the most important in Model View
Controller?
A) Separation of different concerns
B) All request go the same place
C) Easy to test different components
D) Easy to change the view
✔

MVC Patterns
– Page Controller
 View patterns
– Template View
26

Page Controller
An object that handles a request for a specific
page or action on a Web site
 One input controller for each logical page of the
web site
27

Page Controller
 How It Works
– One Page Controller for each logical page
 Page controller as Script
– Servlet or CGI program
– Useful for web application that need some logic and
data
 Page controller as a server page
– ASP, PHP, JSP
– Combines the Page Controller and Template View
– Helpers used to get data from the model
– Works fine if the logic is simple or none
28

Page Controller
 The basic responsibility of a Page Controller are
– Decode the URL and extract any form data to figure
out all data for the action
– Create and invoke any model objects to process the
data.
• All relevant data from the HTML request should be passed to
the model so that the mode objects don’t need any
connection to the HTML request
– Determine which view should display the result page
and forward the information to it
30

Page Controller
 When to Use It
– Works well in a site where the controller logic is
simple
– When the controller logic is simple the Front
Controller adds too much overhead
 Examples
– Simple Display with a Servlet Controller and a JSP
View
– Using a JSP as a Handler
– Page Handler with Code Behind
31

Front Controller
A controller that handles all requests for
a web site
 One controller handles all requests
– The handler dispatches to command objects for
behaviour particular to the request
32

Front Controller
 How It Works
– Takes care of common tasks, for example security,
authentication, i18n, and so on
– Built on Commands
– Usually implemented as script, not page
 Two phases
– Request handling – Web Handler
– Command handling – Command classes
33

Front Controller
 Request handling – Web Handler
– Any common logic
– Authentication, Web Security etc.
– Changes in one place apply for the whole site
– Handler creates the requested command
 Command handling – Command classes
– Specific functionality
– Command classes extend abstract classes and
implements process method
– Can be separated form the web infrastructure
34

Front Controller
 Handler takes the request
– Examines the URL
– Creates command and calls the command
35

Front Controller
 Web handler can have commands statically or
dynamically
– Static case has the advantage of explicit logic and
compile time error checking
– Dynamic case has some property file to map
request URL to command classes
– Dynamic case has more flexibility to add new
commands
36

Front Controller
 When to Use It
– Front controller is more complicated design than the
Page Controller
– Only one controller needs to be configured in the web
server, the handler takes care of the dispatching
– With dynamic commands, you can easily add new
commands
– Single point of entry allowing centralized logic
37

Application Controller
A centralized point for handling screen
navigation and the flow of an application
 Applications that have significant amount of logic
about the screens to use at different points
– For example Wizard style applications
– Screens depend on the state
38

 How it works
– Two responsibilities: Decide which domain logic to
use and deciding the view
39

 Can be used with Command pattern
– Commands execute the domain logic
– Not easy to determine what is domain logic and what
is the application logic
 State machine
– The Controller must maintain a state
 When to Use It
– If the flow and application logic is complex and simple
controllers need to share code
40

MVC Patterns
– Page Controller
 View patterns
– Template View
41

QUIZ
We are designing an application for corporate tax reduction
which have multiple of screens and various conditions and
exceptions. What controller pattern might be useful?
A) Input Controller
B) Page Controller
C) Front Controller
D) Application Controller

QUIZ
We are designing an application for corporate tax reduction
which have multiple of screens and various conditions and
exceptions. What controller pattern might be useful?
A) Input Controller
B) Page Controller
C) Front Controller
D) Application Controller
✔

MVC Patterns
– Page Controller
 View patterns
– Template View
44

Template View
Renders information into HTML by
embedding markers in an HTML page
 Place markers in HTML page that can be
resolved into calls to get dynamic information
45

Template View
 How it Works
– Embed markers into static HTML page when it’s
written
– When the page is used to service a request, the
markers are replaced by the results of some
computation
 Server Pages for presentation
– ASP, PHP, JSP
– Page receives data to work with
– Allow scriptlets
46

Template View
 Embedding the markers
– Markers are used for dynamic data
– <% and %> JSP, ASP
– Tags such as JSTL and customized
– Data is sent with the request
 Helper Objects
– Provide helper object that give the results
– Avoids scriptlets and keeps the code in classes
47

Template View
 Conditional display
– Most Server Pages support conditional tags
– Provides some presentation logic
– Can lead to bad code and should be avoided if
possible
– Try to move the condition into helper object or tags
48
<c:if test="${!empty cookie.userName}">
Welcome back <c:out value="${cookie.userName.value}" />
</c:if>

Example
49
<jsp:include page="top.jsp" flush="true" />
<table cellpadding="4" cellspacing="4" border="0" width="100%">
<tr><td>
<%@ page import="is.ru.honn.domain.User" session="true" %>
<% User user = (User)request.getSession().getAttribute ("user");
if (user == null)
{
%>
<h1>Sportvefurinn</h1>
Ef þú ert nýr notandi getur þú skráð þig með því að smella á <b>Nýskrá</Annars, smelltu á <b>Innskrá</b> til að skrá þig inn á vefinn.
<% } else { %>
<h1>Halló <%= user.getName() %></h1>Smelltu á <b>Leikir</b> til að sjá næstu
<% } %>
</td></tr></table>
<%-- bot.jsp síðan inniheldur restina af HTML síðunni --%>

Template
 Velocity template example

Template
 Scala template example
@(customer: Customer, orders: Seq[Order])
<h1>Welcome @customer.name!</h1>
<ul>
@orders.map { order =>
<li>@order.title</li>
}
</ul>

Template
 Template Engine will execute the view and
create HTML
Template Engine HTML
View Template
Language
reads generates
Model
Parameters

QUIZ
What pattern is described like this?
A) Template View
B) Transform View
C) Model View
D) Two Step View

QUIZ
What pattern is described like this?
A) Template View
B) Transform View
C) Model View
D) Two Step View
✔

MVC Design
57
2. Call the model

Domain and Presentation
 Data from the model need to be accessed by the
view
– Data is simple classes
– Controller handles the flow and decides which view
to call
– View needs access to data
 Two methods
– Use Request if lifetime of
the data is the request
– Use Session if the data
must span many requests 59

Domain and Presentation
 Single Request
– Same request object is used
– Use getParameter to get input
– Store the data in request
using setAttribute
– JSP can access the
data using the
request
60

Combining Model and View
Input Controller
HTTP/HTML handling
Model
Domain Layer
View
Template
Model
Parameters

Trends
 Mobile is bigger than Desktop
– Mobile is the most important platform for many
applications
 The Programmable Web
– If you want to be in the game, you have an API
 When Good Enough is Not Enough
– Rise Apps
– Single purpose programs

Rise of the API
 Separating UI from code
– Model View Controller patterns
 User Interface is HTML5 or Native App
– Server side is just API
– Information format in XML or Json

API Design
 HTTP is designed to be simple
– GET, POST, PUT, DELETE
 Trends was to build on top of this
– SOAP
 SOAP does not use any of the HTTP built in
functionality
– Adds a complexity layer on top

REST Explained Briefly
 REST over HTTP leverages HTTP
– Uses HTTP request methods: GET, POST, PUT,
DELETE
 GET is safe – does not have side effects
– Possible to cache client side
– 80% or more of the requests are GET
 PUT and DELETE are idempotent

REST Explained Briefly
 GET to get resource
 POST to add resource
 PUT to update resource
 DELETE to delete resource

REST examples
 Getting
GET someservice.com/api/customer/3829
 Adding
POST someservice.com/api/customer/
 Updating
PUT someservice.com/api/customer/3829

Play Framework
 Open source web application framework
– Written in Java
– Build and deployment is all handled by scripts
 Follows the model-view-controller architectural
pattern
 Goals
– Optimize developer productivity by using convention
over configuration, hot code reloading and display of
errors in the browser
73

Play MVC
 Model
– Domain specific Java classes
 View
– User Interface
– HTML, XML, JSON
– Scala template language
 Controller
– Java classes that take requests and operate on the
model
– Results are rendered by the view
74

The Request Life Cycle
1. An HTTP Request is received by the framework
2. The Router component tries to find the most
specific route able to accept this request. The
corresponding action method is then invoked
3. The application code is executed
4. If a complex view needs to be generated, a
template file is rendered
5. The result of the action method (HTTP Response
code, Content) is then written as an HTTP
Response
76

Creating a Play app
 Unzip typesafe-activator-1.2.10-minimal.zip
 Open CMD or Terminal
 Run activator
– This will download and install Play Framework
$activaor
 Add activator to PATH
78

Creating a Play app
 Open CMD or Terminal
>activator new RuBook
 Creates a new appliction
>cd RuBook
>play run
 Runs the Web App
 Open a browser and goto localhost:9000
79

Application.java
 input controller
– controllers.Application
– Requests will go to this Java class
86
public class Application extends Controller
{
public static Result index()
{
return ok(index.render("Fagra veröld"));
}

index.html
 View is a Scala template
views/index.scala.html
 Compiles in to class
views/html/index.class
87
@(message: String)
@main("Welcome to Play") {
@message
}

Routing
 conf/routes contains the routing information
88
# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~
# Home page
GET / controllers.Application.index()
# Map static resources from the /public folder to the /assets URL path
GET /assets/*file controllers.Assets.at(path="/public", file)

Errors
 Play displays errors
– CMD has more information
89

Summary
 Web Presenation Patterns
– Model View Controller
– Page Controller
– Template View
 Play framework
90

L17 Presentation Layer Design

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à L17 Presentation Layer Design

Similaire à L17 Presentation Layer Design (20)

Plus de Ólafur Andri Ragnarsson

Plus de Ólafur Andri Ragnarsson (20)

Dernier

Dernier (20)

L17 Presentation Layer Design