The document discusses various design patterns for the presentation layer in web applications, including Model-View-Controller (MVC), templates, and API design. It covers MVC patterns like Model View Controller, Page Controller, Front Controller, and Application Controller. It describes how templates can be used to render dynamic information by embedding markers in HTML pages. It also discusses trends toward designing web applications with application programming interfaces (APIs) that separate the user interface from server-side code.

1. HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015
L13 PRESENTATION LAYER DESIGN

3. HÖNNUN OG SMÍÐI HUGBÚNAÐAR 2015
L13 PRESENTATION LAYER DESIGN

4. Agenda
▪ Web Presentation Patterns
– Model View Controller
– Page Controller
– Front Controller
– Application Controller
– Template View
▪ MVC Design
▪ API Design
▪ Play framework

5. Reading
Model View Controller
Page Controller
Front Controller
Template View
Application Controller

6. Play! Framework
▪ We will be using Play! framework
– Based on MVC

7. 7
The Web Layer

8. 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
8

9. Presentation and Web Layers
▪ Embedded and Desktop clients
▪ Web Browser is a different type of client
9

10. Web Applications

11. 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

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

13. 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
Web Browser
Web
Server
Configuration
file
HTTP Request
HTTP Request
Web Script
Web Page

14. 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
Web Browser
Web
Server
HTTP Request
HTTP Request
Web Application
CodeHTML
JavaScript
Code
Code
Template
DB

15. 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
Web Browser
Web
Server
HTTP Request
HTTP Request
Web Application
HTML
JavaScript
Code
Code
Server
Page DBServer
Page Code

16. Web Design
▪ Web Layer must handle the request and the response
Web
Browser
Web
Layer
Domain Layer Data Source
Layer
HTTP
request Request
Controller
Presentation
View
HTTP
response
Service Layer
Domain Model
Table
Data
Gateway

17. 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
HTTP Request
Json/XML
Json/XML

18. Model-View-Controller

19. Model View Controller
Splits user interface interactions
into three distinct roles
▪ Separates the user interface from the logic
– Originally from 70s Smalltalk
▪ MVC considers three roles
– Clear separations of concerns
– Model: The domain layer handles state
– View: Presentation logic
– Controller: Connects the model and the view

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

21. 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

22. 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

23. MVC in Web Design
Web Applications are request/response based
Input Controller
1. Takes the request
2. Examines the input parameters
3. Calls the Model
4. Decides how to
handle the response
5. Sends the control
to the View for
rendering
6. Returns the Response
Controller
request
Model
View
response

24. MVC in Web Design

25. MVC Patterns
View patterns
Template View
Transform View
Two Step View
Input controller patterns
Page Controller
Front Controller
Application Controller

26. 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

27. 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
✔

28. MVC Patterns
View patterns
Template View
Transform View
Two Step View
Input controller patterns
Page Controller
Front Controller
Application Controller

29. 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

30. 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

31. Page Controller pattern

32. Page Controller
▪ The basic responsibility of a Page Controller are
1. Decode the URL and extract any form data to figure out all data
for the action
2. 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
3. Determine which view should display the result page and forward
the information to it

33. 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

34. 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

35. 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

36. 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
36

37. Front Controller
▪ Handler takes the request
– Examines the URL
– Creates command and calls the command

38. 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

39. 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 centralised logic

40. Application Controller
A centralised 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

41. Application Controller
▪ How it works
– Two responsibilities: Decide which domain logic to use and
deciding the view
41

42. 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
42

43. MVC Patterns
View patterns
Template View
Transform View
Two Step View
Input controller patterns
Page Controller
Front Controller
Application Controller

44. 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

45. 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
✔

46. MVC Patterns
View patterns
Template View
Transform View
Two Step View
Input controller patterns
Page Controller
Front Controller
Application Controller

47. 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

48. 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
48

49. 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

50. 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
<c:if test="${!empty cookie.userName}">
Welcome back <c:out value="${cookie.userName.value}" />
</c:if>

51. Example
51
<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á</b>
í valmyndinni hér til vinstri.
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 leiki.
<% } %>
</td></tr></table>
<%-- bot.jsp síðan inniheldur restina af HTML síðunni --%>
<jsp:include page="bot.jsp" flush="true" />

52. Example

53. Template
▪ Velocity template example

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

55. Template
▪ Template Engine will execute the view and create HTML
Template
Engine HTML
View
Template
Language
reads generates
Model
Parameters

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

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

58. MVC Design

59. MVC Design
2. Call the model

60. MVC Design
60

61. 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
Polymorphism

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

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

64. API Design

65. 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

66. 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

68. 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
HTTP Request
Json/XML
Json/XML

69. 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 has become the preferred way

70. 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

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

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

73. Play Framework

75. 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
– Optimise developer productivity by using convention over
configuration, hot code reloading and display of errors in the
browser
75

76. 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
76

77. Play MVC
77

78. 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

79. 79

80. 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
80

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

82. 82

83. 83

85. 85

86. Play in IntelliJ
86

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

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

90. 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)

91. Errors
▪ Play displays errors
– CMD has more information
91

92. Summary
▪ Web Presentation Patterns
– Model View Controller
– Page Controller
– Front Controller
– Application Controller
– Template View
▪ MVC Design
▪ API Design
▪ Play framework
92