Introduction to the Jakarta Struts Framework

1
Introduction to the Jakarta Struts Framework

• The Topics
• JavaServer Pages (JSP) Overview
• JSP Tags and Tag Libraries Overview
• Model View Controller (MVC) Design Pattern
  Overview
• Struts Details
• Struts Example

2
JavaServer Pages (JSP)

• A JSP file is a java servlet.
• A JSP file is nothing more than another way to
  view a servlet.
• The concept of a JSP file is to allow us to see a
  Java servlet as an HTML page.
• The JSP file is pre-processed into a .java file,
  then compiled into a .class file.
• JSP technology provides the glue between the page
  designer and the Java developer.

3
JSP File-to-Servlet Flow
In case you were wondering, this is significantly
different from a Microsoft Active Server Page
(ASP). An ASP is compiled into memory, not into a
separate file.)
4
The Simple Self-contained JSP File

• In a small JSP application, it is common to see
  the data, business logic, and the user interface
  combined into one module of code.
• In addition, the application generally contains
  the logic that controls the flow of the
  application.

5
The Simple Self-contained JSP File

• In a simple request and response, the JSP file
• Sets the data
• Controls the flow to the next page
• Creates the HTML

6
The Simple Self-contained JSP File

• The advantage of the single-page approach is that
  it is easy to understand and initially easy to
  build.
• Its also, with all the graphical development
  tools, easy to get started.

7
The Simple Self-contained JSP File

• Consequences of the single-page approach.
• Heavy HTML and java coupling.
• The coder of the JSP file must be both a page
  designer and a java developer. The result is
  often either terrible java code or an ugly page,
  or sometimes both.
• Java and JavaScript blur.
• As the pages become larger, there can be a
  tendency to implement some JavaScript. When the
  JavaScript appears in a page, the script can get
  confused with the java code. An example of a
  possible point of confusion is using client-side
  JavaScript to validate the email field.
• Embedded flow logic.
• To understand the entire flow of the application,
  you have to navigate all of the pages. Imagine
  the spaghetti logic on a 100-page web site.

8
The Simple Self-contained JSP File

• Consequences of the single-page approach (cont.)
• Debugging difficulties
• In addition to being ugly to look at, HTML tags,
  Java code, and JavaScript code all in one page
  makes it difficult to debug problems.
• Tight coupling
• Changes to business logic or data means possibly
  touching every page involved.
• Aesthetics
• Visually, in large pages, this type of coding
  looks messy. Even with syntax coloring, it is
  still difficult to read and understand.

9
No More Java Code in My HTML

• In the previous example, instead of having a lot
  of HTML in java code (i.e. doing everything in a
  servlet), we have a lot of java code in an HTML
  file.
• This doesnt really accomplish much, other than
  forcing page designers to write java code.
• All is not lost with JSP 1.1, we have a new
  feature called tags.

10
JSP Tags

• A JSP tag is simply a way of abstracting out code
  from a JSP file.
• For the same reason we dont want to see HTML
  tags in java code, we dont want to see java code
  in a JSP file.

11
JSP Tags

• The entire point of JSP technology is to allow
  the page designer to create servlets without
  being distracted with java code.
• Tags allow java programmers to extend JSP files
  by making java code look like HTML.

12
JSP Tags

• The general concept of pulling the code from the
  JSP page and putting into a JSP tag.

13
JSP Tags

• An example of Struts tag capability

ltformform action"join.do" focus"email" gt
ltformtext property"email" size"30"
maxlength"30"/gt ltformsubmit
property"submit" value"Submit"/gt lt/formformgt
14
JSP Tags

• Resulting HTML sent to the browser

ltform name"joinForm" method"POST
action"join.dojsessionidndj71hjo01"gt
ltinput type"text" name"email" maxlength"30"
size"30" value""gt ltinput type"submit"
name"submit" value"Submit"gt lt/formgt ltscript
language"JavaScript"gt lt!--
document.joinForm.email.focus() // --gt lt/scriptgt
15
JSP Tags

• Notes about JSP tags
• JSP tags require a container that runs JSP 1.1 or
  later.
• JSP tags run on the server and are not
  interpreted by the client like HTML tags are.
• JSP tags provide proper code re-use.

16
JSP Tags

• HTML and JavaScript can be added to pages using a
  JSP mechanism called include.
• Developers have a tendency to create huge
  JavaScript library files, and these libraries are
  included into the JSP file.
• The result is a much larger than necessary HTML
  page returned to the client.
• The proper use of include is for HTML snippets
  for such things as page headers and footers.
• By abstracting out the Java code, JSP tags have
  promoted specialization of development roles.

17
Issues

• JSP tags solved only part of our problem.
• We still have issues
• Validation.
• Flow control.
• Updating the state of the application.

18
Model-view-controller (MVC) Design Pattern

• MVC helps resolve some of the issues with the
  single module approach by dividing the problem
  into three categories
• Model.
• The model contains the core of the application's
  functionality. The model encapsulates the state
  of the application. Sometimes the only
  functionality it contains is state. It knows
  nothing about the view or controller.
• View.
• The view provides the presentation of the model.
  It is the look of the application. The view can
  access the model getters, but it has no knowledge
  of the setters. In addition, it knows nothing
  about the controller. The view should be notified
  when changes to the model occur.
• Controller.
• The controller reacts to the user input. It
  creates and sets the model.

19
Model-view-controller (MVC) Design Pattern
20
Two Different Models

• MVC or JSP Model 1 and Model 2 differ essentially
  in the location at which the bulk of the request
  processing is performed.

Model 1
Model 2
21
Model 1

• In the Model 1 architecture the JSP page alone is
  responsible for processing the incoming request
  and replying back to the client.

22
Model 1

• There is still separation of presentation from
  content, because all data access is performed
  using beans.
• Model 1 architecture is perfectly suitable for
  simple applications but it may not be desirable
  for complex implementations.
• Indiscriminate usage of this architecture usually
  leads to a significant amount of scriptlets or
  Java code embedded within the JSP page

23
Model 2

• A hybrid approach for serving dynamic content.
• It combines the use of both servlets and JSP.

24
Model 2

• The servlet
• performs process-intensive tasks.
• acts as the controller.
• is in charge of the request processing.
• creates any beans or objects used by the JSP.
• Decides, depending on the user's actions, which
  JSP page to forward the request to.

25
Model 2

• The JSP
• generates the presentation layer.
• has no processing logic.
• Is responsible for retrieving any objects or
  beans that may have been previously created by
  the servlet.
• Extracts the dynamic content from the servlet for
  insertion within static templates.

26
Model 2

• Typically results in the cleanest separation of
  presentation from content.
• Leads to clear delineation of the roles and
  responsibilities of the developers and page
  designers.
• The more complex your application, the greater
  the benefits of using the Model 2 architecture
  should be.

27
Jakarta Struts

• Is not . . .

• a pompous step or walk.

• arrogant behavior.

• Is not even . . .

• a structural piece designed to resist pressure
  in the direction of its length.

28
Jakarta Struts Is

• A model-view-controller (MVC) Model 2
  implementation that uses servlets and JavaServer
  pages (JSP) technology.

29
Struts, an MVC 2 Implementation

• Struts is a set of cooperating classes, servlets,
  and JSP tags that make up a reusable MVC 2
  design.
• This definition implies that Struts is a
  framework, rather than a library.
• Struts also contains an extensive tag library and
  utility classes that work independently of the
  framework.

30
Struts Overview
31
Struts Overview

• Client browser
• An HTTP request from the client browser creates
  an event. The Web container will respond with an
  HTTP response.

32
Struts Overview

• Controller
• The Controller receives the request from the
  browser, and makes the decision where to send the
  request.
• With Struts, the Controller is a command design
  pattern implemented as a servlet.
• The struts-config.xml file configures the
  Controller.

33
Struts Overview

• Business logic
• The business logic updates the state of the model
  and helps control the flow of the application.
• With Struts this is done with an Action class as
  a thin wrapper to the actual business logic.

34
Struts Overview

• Model state
• The model represents the state of the
  application.
• The business objects update the application
  state.
• The ActionForm bean represents the Model state at
  a session or request level, and not at a
  persistent level.
• The JSP file reads information from the
  ActionForm bean using JSP tags.

35
Struts Overview

• View
• The view is simply a JSP file.
• There is no flow logic, no business logic, and no
  model information -- just tags.
• Tags are one of the things that make Struts
  unique compared to other frameworks.

36
Struts Details

• A stripped-down UML diagram of the
  org.apache.struts.action package

37
The ActionServlet Class

• The Struts Controller is a servlet that maps
  events (an event generally being an HTTP post) to
  classes.
• The Controller uses a configuration file so we
  dont have to hard-code the values.

38
The ActionServlet Class

• ActionServlet is the Command part of the MVC
  implementation.
• It is the core of the Framework.
• ActionServlet (Command) creates and uses an
  Action, an ActionForm, and an ActionForward.
• The struts-config.xml file configures the
  Command.
• During the creation of the Web project, Action
  and ActionForm are extended to solve the specific
  problem space.

39
The ActionServlet Class

• Command functionality can be added by extending
  ActionServlet.
• The file struts-config.xml instructs
  ActionServlet on how to use the extended classes.

40
The ActionServlet Class

• There are several advantages to this approach
• The entire logical flow of the application is in
  a hierarchical text file. This makes it easier to
  view and understand, especially with large
  applications.
• The page designer does not have to wade through
  Java code to understand the flow of the
  application.
• The Java developer does not need to recompile
  code when making flow changes.

41
The ActionForm Class

• ActionForm maintains the session state for the
  Web application.
• ActionForm is an abstract class that is
  sub-classed for each input form model.
• ActionForm represents a general concept of data
  that is set or updated by a HTML form. E.g., you
  may have a UserActionForm that is set by an HTML
  Form.

42
The ActionForm Class

• The Struts framework will
• Check to see if a UserActionForm exists if not,
  it will create an instance of the class.
• Set the state of the UserActionForm using
  corresponding fields from the HttpServletRequest.
  
• No more request.getParameter() calls. For
  instance, the Struts framework will take fname
  from request stream and call UserActionForm.setFna
  me().
• The Struts framework updates the state of the
  UserActionForm before passing it to the business
  wrapper UserAction.

43
The ActionForm Class

• Before passing it to the Action class, Struts
  will also conduct form state validation by
  calling the validation() method on
  UserActionForm.
• Note This is not always wise to do. There might
  be ways of using UserActionForm in other pages or
  business objects, where the validation might be
  different. Validation of the state might be
  better in the UserAction class.
• The UserActionForm can be maintained at a session
  level.

44
The ActionForm Class

• Notes
• The struts-config.xml file controls which HTML
  form request maps to which ActionForm.
• Multiple requests can be mapped to
  UserActionForm.
• UserActionForm can be mapped over multiple pages
  for things such as wizards.

45
The Action Class

• The Action class is a wrapper around the business
  logic.
• The purpose of Action class is to translate the
  HttpServletRequest to the business logic.
• To use Action, subclass and overwrite the
  perform() method.

46
The Action Class

• The ActionServlet (Command) passes the
  parameterized classes to ActionForm using the
  perform() method.
• No more request.getParameter() calls.
• By the time the event gets here, the input form
  data (or HTML form data) has already been
  translated out of the request stream and into an
  ActionForm class.

47
The Action Class

• Note
• "Think thin" when extending the Action class.
• The Action class should control the flow and not
  the logic of the application.
• By placing the business logic in a separate
  package or EJB, we allow flexibility and reuse.

48
The Action Class

• Another way of thinking about Action class is as
  the Adapter design pattern.
• The purpose of the Action is to "Convert the
  interface of a class into another interface the
  clients expect."
• "Adapter lets classes work together that couldnt
  otherwise because of incompatibility of
  interfaces" (from Design Patterns - Elements of
  Reusable OO Software by Gof).

49
The Action Class

• The client in this instance is the ActionServlet
  that knows nothing about our specific business
  class interface.
• Struts provides a business interface it does
  understand, Action.
• By extending the Action, we make our business
  interface compatible with Struts business
  interface.

50
The Action Class

• The relationship of the Command (ActionServlet)
  to the Model (Action).

51
The Error Classes

• ActionErrors is a container of ActionError
  classes that the View can access using tags.
• ActionErrors is Struts way of keeping up with a
  list of errors.

52
The ActionMapping Class

• An incoming event is normally in the form of an
  HTTP request, which the servlet Container turns
  into an HttpServletRequest.
• The Controller looks at the incoming event and
  dispatches the request to an Action class.

53
The ActionMapping Class

• The struts-config.xml determines what Action
  class the Controller calls.
• The struts-config.xml configuration information
  is translated into a set of ActionMapping, which
  are put into container of ActionMappings.
• Classes that end with s are containers.

54
The ActionMapping Class

• The ActionMapping contains the knowledge of how a
  specific event maps to specific Actions.
• The ActionServlet (Command) passes the
  ActionMapping to the Action class via the
  perform() method.
• This allows Action to access the information to
  control flow.

55
ActionMappings Class

• ActionMappings is a collection of ActionMapping
  objects.

56
Before and After Struts

• A lot of complexity and layers have been added.
• No more direct calls from the JSP file to the
  Service layer.

57
Struts Pros

• Use of JSP tag mechanism
• The tag feature promotes reusable code and
  abstracts Java code from the JSP file. This
  feature allows nice integration into JSP-based
  development tools that allow authoring with tags.
  
• Tag library
• Why re-invent the wheel, or a tag library? If you
  cannot find something you need in the library,
  contribute. In addition, Struts provides a
  starting point if you are learning JSP tag
  technology.

58
Struts Pros

• Open source
• You have all the advantages of open source, such
  as being able to see the code and having everyone
  else using the library reviewing the code. Many
  eyes make for great code review.
• Sample MVC implementation
• Struts offers some insight if you want to create
  your own MVC implementation.

59
Struts Pros

• Manage the problem space
• Divide and conquer is a nice way of solving the
  problem and making the problem manageable.

60
Struts Cons

• Limited scope
• Struts is a Web-based MVC solution that is meant
  be implemented with HTML, JSP files, and
  servlets.
• J2EE application support
• Struts requires a servlet container that supports
  JSP 1.1 and Servlet 2.2 specifications.
• Complexity
• Separating the problem into parts introduces
  complexity. There is no question that some
  education will have to go on to understand
  Struts.
• a.k.a. The Learning Curve (TLC)

61
Presentation Source

• Primary source for this presentation.
• http//www-106.ibm.com/developerworks/library/j-st
  ruts/
• Includes examples
• MVC Model 1 and Model 2 comparison.
• http//www.javaworld.com/javaworld/jw-12-1999/jw-1
  2-ssj-jspmvc.html

62
Other Resources

• Struts homepage
• http//jakarta.apache.org/struts/
• The Jakarta Project
• http//jakarta.apache.org
• Struts Console
• http//www.jamesholmes.com/struts/
• Search on http//www.google.com
• Search criteria jakarta struts

63
Struts Example