The web has become the default and standard user interface for enterprise programming. In this lecture we look at the challenges of adding a web user interface to enterprise systems. The main design pattern we look at is the classical Model View Controller.
The idea is to break user interface components into three distinct roles. The Controller is the entry of the request, and handles the parameters that come with the request. The controller uses the model for the "state" or domain logic, be it calculations or getting some data. The model will deliver some data that needs to be rendered. It is the responsibility of the view to render the user interface.
We will also briefly look at the Play! framework: http://www.playframework.org/
6. 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
7. Presentation and Web Layers
Embedded and Desktop clients
Web Browser is a different type of client
7
9. Web Layer Design
How to design Web Applications
Web Browser
?
Web
Server
HTML/HTTP
Web Application
DB
Server
?
Two approaches
– Script based – Code using HTML
– Server Page based – HTML page with code
9
10. 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
10
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
11
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
12
13. Web Design
Web Layer must handle the request and the
response
13
14. 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
14
16. 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
16
17. Model View Controller
How It Works
– Model: The domain layer handles state
– View: Presentation logic
– Controller: Connects the model and the view
17
18. Model View Controller
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
18
19. Model View Controller
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
19
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
20
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
25. 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
25
26. 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
26
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
28
29. 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
29
30. Front Controller (344)
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
30
31. 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
31
32. 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
32
33. Front Controller
Handler takes the request
– Examines the URL
– Creates command and calls the command
33
34. 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
34
35. 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
35
36. 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
36
37. Application Controller
How it works
– Two responsibilities: Decide which domain logic to
use and deciding the view
37
38. Application Controller
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
38
40. 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)
B)
C)
✔ D)
Input Controller
Page Controller
Front Controller
Application Controller
42. 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
42
43. 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
43
44. 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
44
45. Template View
Conditional display
– Most Server Pages support conditional tags
– Provides some presentation logic
<c:if test="${!empty cookie.userName}">
Welcome back <c:out value="${cookie.userName.value}" />
</c:if>
– Can lead to bad code and should be avoided if
possible
– Try to move the condition into helper object or tags
45
46. Example
<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
<% } %>
</td></tr></table>
46
49. Template
Template Engine will execute the view and
create HTML
reads
View Template
Language
Model
Parameters
generates
Template Engine
HTML
50. Transform View
A view that processes domain data element by
element and transforms it into HTML
Transformation of the domain data into HTML
– Think how elements are transformed
50
51. Transform View
How It Works
– Organized around separate transforms for each kind
of input element
– XSLT (EXtensible Stylesheet Language) is one way
Each object can be serialized into XML which can be
transform to any output using XSLT
When to Use It
–
–
–
–
Comes down to preference
XSLT is awkward to work with without tools
Avoids too much logic in the view
Easy to test and verify the output
51
52. Two Step View
Turns domain data into HTML in two steps: first by
forming some kind of logical page, then
rendering the logical page into HTML
Splits the transformation from domain data to
HTML into two steps
– First transforms the model data into logical page
– Second converts the logical page into HTML
Second step can provide additional elements
– Global changes to big sites
52
53. Two Step View
How It Works
– The process of
transforming the
data to HTML is in
two steps
Intermediate form
– Contains fields,
header, footer, etc.
– Logical information
53
54. Two Step View
When to Use It
– When we need to separate the formatting from the
logical page
– Multi-appearance applications that have the same
functionality but different looks
– When global changes are needed
– The second state can be Template View of
Transform View
54
55. QUIZ
What pattern is described like this?
✔ A)
Template View
B) Transform View
C) Model View
D) Two Step View
59. 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
60. 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
61. Combining Model and View
Input Controller
HTTP/HTML handling
Model
Parameters
View
Template
Model
Domain Layer
64. 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
64
65. Play! features
Stateless: Play is fully RESTful
No configuration: download, unpack and develop
Easy round trips: no need to deploy to an application server
Integrated unit testing: JUnit and Selenium support is
included in the core
Elegant API: rarely will a developer need to import any third
party library
Static methods: all controller entry points and business logic
methods are declared as static
CRUD module: easily build administration UI with little code
Server built in: Jboss Netty web server is used
65
66. Play! MVC
Model
– Domain specific Java classes
View
– User Interface
– HTML, XML, JSON
Controller
– Java classes that take requests and operate on the
model
– Results are rendered by the view
66
68. 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
68
70. Creating a Play! app
Unzip play-2.2.0.zip
Add to path
Open CMD or Terminal
>play new RuBook
Creates a new appliction
>cd RuBook
>play run
Runs the Web App
Open a browser and goto localhost:9000
70
76. Application.java
input controller
– controllers.Application
– Requests will go to this Java class
package controllers;
import play.*;
import play.mvc.*;
import views.html.*;
public class Application extends Controller {
public static Result index() {
return ok(index.render("Your new application is ready."));
}
76
77. index.html
View is views.index.scala.html
@(message: String)
@main("Welcome to Play") {
@play20.welcome(message, style = "Java")
}
77
78. Routing
conf/routes contains the routing information
# 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)
78