Struts2 course chapter 1: Evolution of Web Applications

1. 1

2. 2
Struts2 course topics
• Chapter 1: Evolution of web applications
• Chapter 2: Struts2 Installation and configuration
• Chapter 3: Actions and results
• Chapter 4: OGNL - Object-Graph Navigation Language
• Chapter 5: Form Tags
• Chapter 6: Generic Tags
• Chapter 7: type conversion
• Chapter 8: Input validation
• Chapter 9: Message Handling and Internationalization
• Chapter 10: Model Driven and Prepare Interceptors
• Chapter 11: The Persistence Layer
• Chapter 12: File upload and File download
• Chapter 13: Securing Struts2 applications in Tomcat
• Chapter 14: Custom Interceptors
• Chapter 15: Custom Result Types
• Chapter 16: Preventing Double Submits
• Chapter 17: The Execute and Wait Interceptor
• Chapter 18: Decorating Struts2 with Tiles
• Chapter 19: Decorating Struts2 with SiteMesh
• Chapter 20: Zero Configuration
• Chapter 21: AJAX

3. 3
Evolution of web applications
Agenda
• Live without MVC
• Using the mediator pattern
• MVC model 1
• MVC model 2
• Struts1 implementation of MVC2
• Struts2 implementation of MVC2

4. 4
Live without MVC

5. 5
Live without MVC
Home Catalog
Login Checkout
Caos

6. 6
No MVC – Improved
Using the mediator pattern

7. 7
No MVC – Improved
Using the mediator pattern
Home Catalog
Login Checkout
Mediator
Better!!!

8. 8
Model View Controller (MVC)

9. 9
Model View Controller (MVC)
• Definition of MVC
– Model–View–Controller (MVC) is an architectural pattern
used in software develpment.
– The pattern isolates business logic from user interaction
(input or control) and presentation, permitting
independent development, testing and maintenance of
each one.
– In this case the controller implements the mediator
patters

10. 10
Model View Controller (MVC)
Controller
View
Model
Model
Represents the data on which the
application operates.
View
Renders the model into a form
suitable for interaction, typically a
user interface element. Multiple
views can exist for a single model for
different purposes.
Controller
Processes and responds to events
(typically user actions) and may
indirectly invoke changes on the
model.

11. 11
MVC model 1

12. 12
MVC model 1
JSP
Java
Beans
Browser
Request
Response
Database

13. 13
MVC model 1
• Shortcomings of MVC1
– The model is page - centric
– Difficult of code maintenaince
– Mixing of HTML + Java code is a problem

14. 14
MVC model 1 - Exercise
• Example of MVC 1
implementation using Servlets /
JSP
– struts2-01a

15. 15
MVC model 1 - Exercise
• Objective
Note this

16. 16
MVC model 1 - Exercise
Controller
Model
View

17. 17
MVC model 1 - Exercise
// ControllerServlet.java
String action = request.getParameter("action");
// execute an action
if (action.equals("displayAddProductForm")) {
// Action for displayAddProductForm
} else if (action.equals("saveProduct")) {
// Populate the model
ProductTO product = new ProductTO();
product.setProductName(request.getParameter("productName"));
product.setDescription(request.getParameter("description"));
product.setPrice(request.getParameter("price"));
// code for persisting the ProductTO object goes here
request.setAttribute("product", product);
}
// forward to a view
String dispatchUrl = null;
if (action.equals("displayAddProductForm")) {
dispatchUrl = "/jsp/displayAddProductForm.jsp";
} else if (action.equals("saveProduct")) {
dispatchUrl = "/jsp/displaySavedProduct.jsp";
}
if (dispatchUrl != null) {
RequestDispatcher rd = request.getRequestDispatcher(dispatchUrl);
rd.forward(request, response);
}
Code hard to maintain
Mixing view, model
and controller

18. 18
MVC model 2

19. 19
MVC model 2
Servlets
(controller)
Java
Beans
(Model)
Browser
Request
Response
Database
JSP
(view)

20. 20
MVC model 2
• Benefits of Model 2
– rapid to build
– easier to test
– easier to maintain
– easier to extend

21. 21
MVC model 2 - Exercise
• Example of MVC2
implementation
using Servlets / JSP creating our
own framework
– struts2-01b

22. 22
MVC model 2 - Exercise
• Objective
Note this

23. 23
MVC model 2 - Exercise
Controller
Model
View
View manager
Action manager

24. 24
MVC model 2 - Exercise
// ControllerServlet.java
ActionManager actionManager = new ActionManager();
actionManager.execute(request, response);
ViewManager viewManager = new ViewManager();
viewManager.execute(request, response);

25. 25
MVC model 2 - Exercise
• Conclusion
• By spliting the work into an ActionManager and a
ViewManager you can get a clearer and more
maintainable code
• Framweorks as Struts and Struts2 have already
built-in action and view managers making easy for
us the development

26. 26
Struts1 implementation of
MVC2

27. 27
Struts1 implementation of
MVC2
Controller
Servlet
Browser
Request
Response
View
JSP
Action
Dispatch
Model
Forward

28. 28
Struts1 implementation of
MVC2

29. 29
Struts1 implementation of
MVC2
• Advantages of struts ( 1 or 2)
– page navigation management
– user input validation
– consistent layout
– extensibility
• If you uses Struts you should stick to the following unwritten
rules:
– No Java code in JSPs, all business logic should reside in
Java classes called action classes.
– Use the Expression Language (if you are using JSP 2.0) or
JSTL in JSPs to access business model.
– Little or no writing of custom tags (because they are hard
to code).

30. 30
Struts1 implementation of
MVC2 - Exercise
• Example of MVC2
implementation
using Struts1
– struts2-01c

31. 31
Struts1 implementation of
MVC2 - Exercise
• Objective
Note this

32. 32
Struts1 implementation of
MVC2 - Exercise
Model
View
Controller

33. 33
Struts1 implementation of
MVC2 - Exercise
• Struts-config.xml (controller)
<struts-config>
<action-mappings>
<action path="/displayAddProductForm“
forward="/jsp/displayAddProductForm.jsp" />
<action path="/saveProduct" scope="request"
type="app01c.action.SaveProductAction">
<forward name="success“
path="/jsp/displaySavedProduct.jsp" />
</action>
</action-mappings>
</struts-config>

34. 34
Struts2 implementation of
MVC2

35. 35
Struts2 implementation of
MVC2
Controller
Filter
Browser
Request
Response
View
JSP
Action /
Result
Interceptors
Interceptors

36. 36
Struts2 implementation of
MVC2

37. 37
Struts2 implementation of
MVC2 - Exercise
• Example of MVC2
implementation
using Struts2
– struts2-02a

38. 38
Struts2 implementation of
MVC2 - Exercise
• Objective
Note this

39. 39
Struts2 implementation of
MVC2 - Exercise
Model
View
Controller

40. 40
Struts2 implementation of
MVC2 - Exercise
• Struts.xml (controller)
<package name="app02a" namespace=""
extends="struts-default">
<action name="Product_input">
<result>/jsp/Product.jsp</result>
</action>
<action name="Product_save"
class="app02a.Product" method="execute">
<result>/jsp/Details.jsp</result>
</action>
</package>

41. 41
Struts1 vs Struts2 comparison
Feature Struts 1 Struts 2
Action
classes
Struts 1 requires Action classes to
extend an abstract base class. A
common problem in Struts 1 is
programming to abstract classes
instead of interfaces.
An Struts 2 Action may implement
an Action interface, along with other
interfaces to enable optional and custom
services. Struts 2 provides a base
ActionSupport class to implement commonly
used interfaces. Albeit, the Action interface
is not required. Any POJO object with
a execute signature can be used as an Struts
2 Action object.
Threading
Model
Struts 1 Actions are singletons and
must be thread-safe since there will
only be one instance of a class to
handle all requests for that Action.
The singleton strategy places
restrictions on what can be done
with Struts 1 Actions and requires
extra care to develop.
Struts 2 Action objects are instantiated for
each request, so there are no thread-safety
issues. (In practice, servlet containers
generate many throw-away objects per
request, and one more object does not
impose a performance penalty or impact
garbage collection.)

42. 42
Struts1 vs Struts2 comparison
Servlet
Dependency
Struts 1 Actions have dependencies
on the servlet API since the
HttpServletRequest and
HttpServletResponse is passed to
the execute method when an
Action is invoked.
Struts 2 Actions are not coupled to a
container. Most often the servlet contexts
are represented as simple Maps, allowing
Actions to be tested in isolation.
Struts 2 Actions can still access the original
request and response, if required. However,
other architectural elements reduce or
eliminate the need to access the
HttpServetRequest or HttpServletResponse
directly.
Testability A major hurdle to testing Struts 1
Actions is that the execute method
exposes the Servlet API. A third-
party extension, Struts TestCase,
offers a set of mock object for
Struts 1.
Struts 2 Actions can be tested by
instantiating the Action, setting properties,
and invoking methods. Dependency
Injection support also makes testing simpler.

43. 43
Struts1 vs Struts2 comparison
Harvesting
Input
Struts 1 uses an ActionForm object
to capture input. Like Actions, all
ActionForms must extend a base
class. Since other JavaBeans cannot
be used as ActionForms, developers
often create redundant classes to
capture input.
DynaBeans can used as an
alternative to creating conventional
ActionForm classes, but, here too,
developers may be redescribing
existing JavaBeans.
Struts 2 uses Action properties as input
properties, eliminating the need for a second
input object. Input properties may be rich
object types which may have their own
properties.
The Action properties can be accessed from
the web page via the taglibs. Struts 2 also
supports the ActionForm pattern, as well as
POJO form objects and POJO Actions.
Rich object types, including business or
domain objects, can be used as input/output
objects. The ModelDriven feature simplifies
taglb references to POJO input objects.
Expression
Language
Struts 1 integrates with JSTL, so it
uses the JSTL EL. The EL has basic
object graph traversal, but
relatively weak collection and
indexed property support.
Struts 2 can use JSTL, but the framework also
supports a more powerful and flexible
expression language called "Object Graph
Notation Language" (OGNL).

44. 44
Struts1 vs Struts2 comparison
Type
Conversion
Struts 1 ActionForm properties are
usually all Strings. Struts 1 uses
Commons-Beanutils for type
conversion. Converters are per-
class, and not configurable per
instance.
Struts 2 uses OGNL for type conversion.
The framework includes converters for
basic and common object types and
primitives.
Validation Struts 1 supports manual validation
via avalidate method on the
ActionForm, or through an
extension to the Commons
Validator. Classes can have
different validation contexts for the
same class, but cannot chain to
validations on sub-objects.
Struts 2 supports manual validation via
the validate method and the XWork
Validation framework. The Xwork
Validation Framework supports chaining
validation into sub-properties using the
validations defined for the properties
class type and the validation context.
Control Of
Action
Execution
Struts 1 supports separate Request
Processors (lifecycles) for each
module, but all the Actions in the
module must share the same
lifecycle.
Struts 2 supports creating different
lifecycles on a per Action basis via
Interceptor Stacks. Custom stacks can be
created and used with different Actions,
as needed.

45. 45
Struts2 Architecture

46. 46
Struts2
Architecture

47. 47
Struts2 Architecture
• DO NOT WORRY!!!
• You do not need to understand everything now
• Just understanding what is the action and the result you get
90% what you need of the framework

48. 48
Resources
http://struts.apache.org
To download example code for this chapter go to:
http://www.jeetrainers.com