emptyslowInternet and Web Development

Nov 12, 2013 (3 years and 8 months ago)



Architectural Style


MVC Pattern


J2ME (Thursday)

MVC: Problems with GUI programs

User interfaces are especially prone to changes
in requirements

New types of input





New types of output

Porting to different “look

Information visualization: charts, graphs, plots

Output device heterogeneity: PDAs, applets, Javascript,
HTML, Swing

MVC: Problems with GUI programs

New features require user

User must have a way to access the feature

ex. Add in
text spellcheck to word processor

MVC: Changes Required for
SpellCheck Feature

Changes to input: Need to input
corrections and update the underlying
document model

Changes to underlying document model:

MVC Example: Simple
Spreadsheet System

Consider a simple spreadsheet system for
entering data and viewing charts

Without major impact to the system, it
should be possible to:

Add a new non
interactive view of the data

Add a new interactive view of the data

MVC Example: Simple
Spreadsheet System

Controller Style

Divides interactive application into three types of

Model: Contains core functionality and data

View: Displays information to the user

Controller: Handles user input

Goals: Separation of concerns


Organizes code structure

Independent development

Change propagation (implicit invocation)
mechanism ensures consistency between user
interface and model

Works differently in J2EE

MVC Behavior

Controllers receive events from
manipulation of interface

May or may not be integrated with View

Translate event into operations on the

Each View registers itself with the Model
through implicit invocation

When the Model changes all Views are
automatically updated consistently

MVC Pattern

Original J2EE Architecture (Model 1)

Web browser directly accesses JSP pages

No MVC architecture

Each JSP page processes its own inputs

Manages cookies, sessions, request

JSP includes logic to choose next page to

Hard to modify application flow

MVC in J2EE (Model 2)

Introduces a controller between the
browser and the JSP pages

Controllers centralize the logic for
dispatching requests to the next view

Controllers handle view selection, which
decouples JSP pages from one another

View accesses the Model directly

No implicit invocation

Recall HTTP limitations

MVC Summary in J2EE

The Web
tier controller receives each incoming HTTP request

Invokes the requested operations on the application model

Based on the results of the operation and state of the model, the
controller then selects the next view to display

Finally, the controller generates the selected view and transmits it to
the client for presentation

Model 2 Design

Coupling vs. Cohesion

One giant Controller for entire web site

One controller for each possible event

Each controller should handle relatively independent
state machines (
page flow

Logging in


Playing a game


Enables reusable
web modules

Controllers, associated Views, and model Beans

Loosely coupled, resusable application parts

Not explicitly part of the Spring Framework

Decouples controllers from irrelevant model elements

Spring MultiActionController

Enables each controller to export several methods

Methods are dispatched by Spring Framework

Simplifies controller logic enabling more modular design

import org.springframework.web.servlet.mvc.multiaction.MultiActionController;

public class TicketController extends MultiActionController {

public ModelAndView reserve(HttpServletRequest req, HttpServletResponse res)


//perform logic to reserve a ticket based on the request coming in


public ModelAndView cancel(HttpServletRequest req, HttpServletResponse res)


//perform logic to cancel a reservation based on the request coming in



Spring MultiActionController


Specify the MultiActionController for your controller class

Set the methodNameResolver property

<bean id="paramMultiController“ class=“TicketController">

<property name="methodNameResolver">

<ref bean="paramResolver"/>



Create a ParameterMethodNameResolver referred to by controller

Set the paraName property to the URL parameter specifying method to call

ex. http://localhost:8080/springapp/login?method=newUser

<bean id="paramResolver"


<property name="paramName">





Page Flow

Controllers implement page flow

JSPs do not refer to one another

Controller dynamically chooses the "next"

Next view (page) to display depends on:

Results of any operation on the application

Session state

URL and Request parameters

Form input

Login Controller Example

Next view to display after a sign on very
likely depends on:

The user id and password contained in the

The success or failure of the sign on

Other server
side state

maximum number of allowed users

the URL the user was trying to access


Many web applications present multiple
Views on a single web page

Need to keep consistent layout

Keep views consistent with model updates

Avoid using frames

Enables modular decomposition

Templating Example

Templating Steps

1. Create a ModelEnvironment Bean

2. Insert all “model beans” into the
ModelEnvironment using bean configuration

3. Create a PageChooser Bean

4. Create a Template JSP

5. Use PageChooser and ModelEnvironment in

6. Use PageChooser and ModelEnvironment in

Templating: ModelEnvironment

Model environment bean will store all the model

Allows multiple views to have access to different model

class ModelEnvironment


private Map model;

//Getters and Setters


Templating: Bean Configuration

Use Bean configuration to put all model beans in the model environment

Use qualified names to separate namespaces for web modules

This is good design but not enforced by the framework



Bean definitions for userInfo and gameState


Hookup beans to Controllers

<bean id=“modelEnvironment” class=“ModelEnvironment”>

<property name=“model”>


<key name=“

<ref bean=“userInfo”/>


<key name=“

<ref bean=“gameState”/>






Templating: PageChooserBean

Allows controller to change multiple views

public class PageChooserBean


private String banner;

private String navigationMenu;

private String body;

private String footer;

//Getters and Setters


Templating: Template JSP

Example Template Page






<jsp:include page=“${model.chooser.banner}”/>




<jsp:include page=“${model.chooser.navigationBar”/>


<jsp:include page=“${model.chooser.body”/>




<jsp:include page=“${model.chooser.footer}”/>






Templating: Template JSP

Use “include” tag to dynamically choose JSP

Recall ${name} is used by JSP to retrieve
variables from a Map type passed in by

Included JSP pages can refer to model variables
in their namespace

ex. ${model.login.userInfo}

“model” is name given by controller

“login” is web module name

“userInfo” is bean name given in bean configuration

Templating: Controller use

Controllers will have reference to model environment and page chooser bean

Controllers can set multiple views by changing the page chooser bean

Controllers will return template JSP and model environment for each request

import org.springframework.web.servlet.mvc.multiaction.MultiActionController;

public class TicketController extends MultiActionController {

private Map globalModelMap;

private TemplateBean pageChooserBean;

public ModelAndView reserve(HttpServletRequest req, HttpServletResponse res) {

//Main controller code



return new ModelAndView(“template”,”model”,globalModelMap);


public ModelAndView cancel(HttpServletRequest req, HttpServletResponse res) {

//perform logic to cancel a reservation based on the request coming in


//Getters and Setters


Templating: Web Module Design

Accessing the model from Controller

Hookup model beans to Controllers using configuration

Do not access the ModelEnvironment directly from controllers
(ModelEnvironment is for JSPs)


Connections between controllers and model components are clear in
configuration and controller code

Connections are statically typed

No casts are necessary

What if a JSP from one module,
, needs to refer to a
bean from another module,

Do not access the other module namespace directly in JSP

Hookup the bean from module B to a bean in module A

Access the required bean through the bean in module A


Connections between modules are clear in configuration

Connections between modules should not be hidden in JSPs

Conclusion: MVC and J2EE

MVC Architectural Style

Good separation of concerns

Divides interactive application into three types of

Updates are propagated through implicit invocation

Model 1 and Model 2 Architecture

J2EE does not use implicit invocation

Page flow and Controller decomposition


Web site templating