Building Web Applications With The Struts Framework  Craig McClanahan Amy Roh  Slides:   apache

Building Web Applications With The Struts Framework Craig McClanahan Amy Roh Slides: apache PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Tutorial Outline. Technology BackgrounderIntroduction To StrutsOur First Struts ApplicationWeb Application Architecture DecisionsA More Advanced Struts ApplicationStruts and Emerging TechnologiesInformation Resources. Technology Backgrounder . Technology Backgrounder. Struts is based on a host of foundational technologiesIt behooves web application developers to be familiar with the basic characteristics of these technolgoiesWorld Wide Web (WWW) Standards:HTTP, HTML, JavaScriptJava API273

Download Presentation

Building Web Applications With The Struts Framework Craig McClanahan Amy Roh Slides: apache

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

1. Building Web Applications With The Struts Framework Craig McClanahan Amy Roh Slides: O’Reilly Open Source Convention July 7 - 11, 2003

2. Tutorial Outline Technology Backgrounder Introduction To Struts Our First Struts Application Web Application Architecture Decisions A More Advanced Struts Application Struts and Emerging Technologies Information Resources

3. Technology Backgrounder

4. Technology Backgrounder Struts is based on a host of foundational technologies It behooves web application developers to be familiar with the basic characteristics of these technolgoies World Wide Web (WWW) Standards: HTTP, HTML, JavaScript Java API Standards: Servlet, JavaServer Pages (JSP)

5. Technology Backgrounder: HTTP Hypertext Transfer Protocol (HTTP) is the fundamental communications protocol of the World Wide Web Simple to implement (client and server) Request/response oriented Stateless (no client identity across requests) HTTP/1.0 – TCP connection per request HTTP/1.1 – Supports persistent connections, for better throughput

6. Technology Backgrounder: HTTP So, what really happens when you type a URL like http://localhost:8080/index.html into your browser's location bar? Your browser sends the following text, with CR/LF at the end of each line (signified by the ? symbol): GET /index.html HTTP/1.1? Host: localhost:8080? If-Modified-Since: (cache-timestamp)? User-Agent: (browser-id-string)? ?

7. Technology Backgrounder: HTTP And the server returns something like this: HTTP/1.1 200 OK? Last-Modified: Fri, 30 May 2003 12:56:38 GMT? Content-Type: text/html? Content-Length: xxx? Server: Apache-Coyote/1.1? ? <html> <head> <title>Welcome To My Web Site</title> </head> ...

8. Technology Backgrounder: HTTP Does the “.html” extension mean that this response was from a static HTML page? Only your server knows for sure :-) How do redirects work? HTTP/1.1 302 Temporary Redirect? Location: What about BASIC authentication? HTTP/1.1 401 Not Authorized? WWW-Authenticate: Basic realm=”Log In”?

9. Technology Backgrounder: HTTP Significant issues for developers: HTTP is stateless, so we need a way to tie requests from the same user together Servlet API uses cookies or URL rewriting Browsers can cache responses per URL: Server returns “Not Modified” (304) status instead of the response content Usually not what you want for dynamic web applications

10. Technology Backgrounder: HTTP Significant issues for developers: What does a URL mean? Significant debate in the web architecture community As we will see, Struts decouples URLs from the content they return Web Applications != Web Sites Browsers have Bookmarks Browsers have Back Buttons

11. Technology Backgrounder: HTML HTTP is agnostic to the content type it is carrying Defined by the “Content-Type” header Common content types include “text/html”, “text/xml”, “image/gif”, ... Official content types are registered with the Internet Engineering Task Force (IETF) Hypertext Markup Language (HTML) is very common, because it is used by many web browsers

12. Technology Backgrounder: HTML Official standards for HTML (as well as other web-related standards like Cascading Style Sheets (CSS)) are developed by the World Wide Web Consortium (W3C) Current “official” version of HTML is 4.01 But many (most!) browsers support non-portable extensions Struts only supports standard elements and attributes

13. Technology Backgrounder: HTML Recent standards activities focused on recasting HTML into an XML-compatible document type: XHTML Allows pre-processing and post-processing by XML-compliant tools Requires more careful editing of source documents to ensure “well-formed” and “valid” content is produced Struts supports an option to render XHTML output instead of HTML <html:html ... xhtml=”true”/>

14. Technology Backgrounder: HTML Significant issues for developers: Browsers support different (and sometimes incompatible) versions of HTML You can look at the “User-Agent” header to make programmatic decisions But some browsers can or will lie to you Be very careful when you allow users to enter marked-up HTML into a database, and then render it as part of your page Very easy to create “cross site scripting” vulnerabilities

15. Technology Backgrounder: JavaScript JavaScript support (in some fashion) is embedded in almost every popular web browser currently available But you cannot count on your users having it enabled Original definition came from Netscape Supports accessing and manipulating the DOM of the client browser Currently standardized as ECMAScript is under the auspices of ECMA International

16. Technology Backgrounder: JavaScript From the perspective of the server, JavaScript code is part of the response content ... it is not special JavaScript event handlers execute on the client, rather than the server Can be embedded in a page, or referenced in a separate resource Can be hand coded by the page author, or generated dynamically by web applications

17. Technology Backgrounder: JavaScript Struts support for JavaScript includes: Standard HTML event handler attributes (onsubmit, onmouseover, ...) available on all relevant HTML tags Form tag “focus” attribute uses JavaScript to initialize the position of the cursor on a newly rendered form Validator Framework can optionally generate client-side JavaScript to implement the same correctness checks that will be performed on the server side.

18. Technology Backgrounder: Java No, we're not going to try to learn how to program in Java here :-) Large numbers of web resources, books, and magazine articles are available Instead, we'll look at some particular issues relevant to web application development

19. Technology Backgrounder: Java Java supports multithreaded applications There can be more than one thread of execution running your code On a multiprocessor machine, this can be happening literally at the same time The JVM maintains a stack containing the local variables for each thread Instance variables in the same object instance are shared across threads Same for static variables in the same class

20. Technology Backgrounder: Java Java supports a multiple class loader environment Class loaders arranged in a parent-child hierarchy Request to load a class starts from the top, down to the loader that loaded the calling class Class ABC loaded from class loader 1 is not the same as class ABC loaded from class loader 2 Even if the bytecodes are identical!

21. Technology Backgrounder: Servlet API Java standard API for writing HTTP-based web applications Developer creates a servlet that responds to individual requests Single instance of each servlet is created Created at startup time or on first request Multithreaded calls to doXxx() per request Cleaned up at shutdown time

22. Technology Backgrounder: Servlet API public class MyServlet extends HttpServlet { ... public void doGet(HttpServletRequest req, HttpServletResponse res) throws ... { // Set HTTP headers on the response res.setContentType(“text/html”); // And write the response content PrintWriter writer = res.getWriter(); writer.println(“<html>”); ... } ... }

23. Technology Backgrounder: Servlet API Servlets are combined into a web application Packaged in a web application archive (WAR) file JAR file with particular layout Configured using a web application deployment descriptor (/WEB-INF/web.xml) file Bound to a context path like “/shopping”

24. Technology Backgrounder: Servlet API Request URLs are mapped to individual servlets via (context relative) URL patterns /foo – Exact match /foo/* -- Starts with specific string *.foo – Ends with specific extension All components of URL available on HttpServletRequest object via methods

25. Technology Backgrounder: Servlet API Sessions provide a mechanism to work around HTTP statelessness Session identifier passed back and forth with client via cookie or URL rewriting Session lives on server in between requests Programmatic timeout interval between requests Container Managed Security supports authentication and authorization of users Won't be covered in this tutorial

26. Technology Backgrounder: Servlet API Event Listeners for lifecycle events: Application creation/shutdown/attributes Session creation/shutdown/attributes (Servlet 2.4 or later) Request creation/shutdown/attributes Filters allow composition of processing pipelines. Examples: “Roll your own” authentication Post process generic XML output with user specific XSLT transformation

27. Technology Backgrounder: Request Dispatcher supports composition and delegation Include – Incorporates output from a separate servlet into a composite result Similar to “server side include” in a web server Forward – Delegates creation of output for this request to a different servlet Behaves like a “server side go-to” Client has no clue this happened (URL does not change in location bar)

28. Technology Backgrounder: Servlet API Significant issues for developers: Multithreading Instance variables should not be used for per-request state information Session attributes need to be threadsafe Class Loading Each web application has its own class loader Most containers support shared parent class loaders Not all code can be shared!

29. Technology Backgrounder: Servlet API Significant issues for developers: HTTP requires headers at the beginning of the response Container buffers output until “committed” Web application deployment descriptor has element ordering requirements Fixed in Servlet 2.4 In the mean time, easier to use a tool Mixing presentation and business logic in a Java class can be hard to maintain

30. Technology Backgrounder: JavaServer Pages (JSP) Servlets embed dynamic logic and markup generation in Java JavaServer Pages embed dynamic logic in static markup (typically HTML) Application server converts each page into a servlet and compiles it Dynamic logic embedded with scriptlets, expressions, or custom actions (tags)

31. Technology Backgrounder: JSP <%@ page contentType=”text/html” %> <%@ taglib prefix=”fmt” uri=”...” %> <html> <head><title>Hello, World</title></head> <body> Hello <%= request.getRemoteUser() %>! Today's date is <fmt:formatDate value=”${now}”/> </body> </html>

32. Technology Backgrounder: JSP Scriptlets let you embed Java code in your JSP pages That can be good ... full power of Java That can be bad ... O-O syntax, wordy Custom Actions (custom tags) let Java developers create reusable classes for: Interacting with business logic Creating markup dynamically

33. Technology Backgrounder: JSP Standard Actions provided for common requirements: <jsp:useBean> <jsp:getProperty> <jsp:include> JSP Standard Tag Library (JSTL) covers other basic needs (iteration, conditionals, XML processing, i18n, ...)

34. Technology Backgrounder: JSP Significant issues for developers: Since a JSP is a servlet, you can leverage all of the capabilities of the Servlet API Since a JSP is a servlet, all of the servlet issues continue to apply In particular, mixing presentation and business logic in a JSP can be hard to maintain

35. Introduction To Struts

36. The Origin Of Struts Like many open source projects, Struts started with me scratching my own itch: Take a US-centric application to Europe ... In multiple languages (4 initially) ... And make it available on the web ... I was familiar with Java and open source Apache JServ and Tomcat containers But there was no good model for a web application architecture available

37. The Origin Of Struts The JSP 0.91 Specification described two fundamental approaches: Model 1 – A resource (such as a JSP page) is responsible for both creating the markup for a form, and for processing the resulting submit Model 2 – A resource (such as a JSP page) is responsible solely for creating the markup; processing the submit is dispatched to a separate resource

38. The Origin Of Struts The second approach sounded better Resources for creating markup and performing database updates are separated So they can be built by different people So they can be built with different technologies So, I built a home grown architecture based on the “Model-View-Controller” paradigm popular in client-server applications

39. Model-View-Controller (MVC) Model – The persistent data (typically in a database) and business logic functionality View – The user interface (typically HTML forms in a web application) Controller – Management software to dispatch form submits to the corresponding business logic, and trigger the display of the appropriate next page

40. MVC As Implemented In Struts

41. Struts Features: Model Tier Struts includes only minimal infrastructure for the model tier A basic implementation of javax.sql.DataSource is included ... But you can integrate any desired approach

42. Struts Features: View Tier Form Beans: Represent the server side state of the input fields on an HTML form Contains hooks for resetting fields to default values (needed for checkboxes) and input field validation DynaActionForm means you do not have to create new JavaBeans yourself

43. Struts Features: View Tier Validation Framework: Abstract input validation rules into separate XML document Extensible for custom field checking Optionally generates client-side JavaScript Always checks on server side Integrated with standard ActionForm beans and DynaActionForm beans

44. Struts Features: View Tier (JSP) Custom Tag Libraries: Bean – General purpose bean and property manipulation Html – Dynamic HTML-based user interfaces (including input forms) Logic – Conditionals and iteration Nested – Versions of other tags that access nested JavaBean hierarchies easily Tiles – Layout management (next page)

45. Struts Features: View Tier (JSP) Tiles Framework: Supports templating for common look and feel of all pages in a web app Tile definitions created in JSP page or in external XML document Definitions can extend base definitions Advanced techniques for dynamically passing information to tiles

46. Struts Features: Controller Tier Configuration Document Defines Behavior Action URLs mapped to Actions Data sources Exception handlers Form beans Forwarding URLs mapped to Pages Message Resources for i18n PlugIns for Lifecycle Management One or more documents allowed

47. Struts Features: Controller Tier Request Processing Lifecycle Extract action mapping path Select locale (if necessary) Select action mapping to utilize Perform role-based access checks Server-side validation (if requested) Invoke application Action Forward based on application outcome Highly customizable and extendable

48. Struts Features: Controller Tier Sub-Application Modules Logically divide single web application into multiple Struts “mini-applications” Session state shared across all modules Standard Action Implementations: Forward or include other URLs Dispatch to one of several methods in an Action class Switch from one sub-application module to another

49. Struts Features: Miscellaneous Jakarta Commons Libraries BeanUtils – Access bean properties dynamically, support DynaBeans Collections – Extensions to Java2 Collections Classes (java.util) Digester – Parse XML documents and configuration files FileUpload – Support <input type-=”file”> Lang – Extensions to core JDK classes (java.lang)

50. Struts Features: Miscellaneous Jakarta Commons Libraries Logging – Abstract logging layer over Log4J, JDK 1.4 logging, or others Validator – Validation framework that can be used in the business logic tier Jakarta-ORO regular expression processing

51. Struts Features: Miscellaneous Extensive documentation and Javadocs Wide variety of third party resources Example web applications: “Blank” starter application Simple basic example Exercise individual tags General and specific documentation on all Struts features

52. Our First Struts Application

53. The Canonical Struts Example Delivered as webapps/struts-example.war in a Struts distribution Can be dropped in to any Servlet 2.2 / JSP 1.1 (or later) container to verify proper support for Struts Simulates (the beginnings of) a web application acting as a proxy for one or more IMAP or POP3 mail subscriptions Let's take a look at its the app in action ...

54. The Configuration Files web.xml – Webapp deployment descriptor “ActionServlet” is the controller Multiple configuration files supported Typically loaded at startup time Mapped to extension pattern (*.do) or path prefix pattern (/do/*) Identifies the application “Welcome File” (JSP 1.1 only) Must declare tag library descriptors

55. The Configuration Files struts-config.xml – Struts configuration Form beans (one dynamic, one standard) Global exceptions (none in this app) define handlers for exceptions of particular types Global forwards provide logical names for physical pages Action mappings map URLs to Actions Can nest local <exception> and <forward> definitions

56. The Configuration Files struts-config.xml – Struts configuration Controller has global configuration settings Message resources elements load sets of localized message text for i18n Plug ins provide lifecycle (webapp start and stop) support for extensions struts-config-registration.xml – Illustrates that you can use multiple config files struts-config_1_1.dtd – Documents content of Struts configuration file elements

57. Walk Through: Logon Processing Start on /index.jsp, second hyperlink: <html:link page=”/logon.jsp”> <bean:message key=”index.logon”/> </html:link> Generated source is localized: <a href=”/struts-example/logon.jsp”> Log on to the MailReader Demo ...</a> Automatic URL encoding supplied also Direct link to JSP page is unusual Useful only in “no setup” situations

58. Walk Through: Logon Processing The /logon.jsp page is displayed Contains a custom form tag: <html:form action=”/logon” focus=”username” onsubmit=”...”> Action attribute matches configured <action> element Focus positions cursor via JavaScript Onsubmit ties in to validation processing Two input fields plus submit/reset buttons Tags generate “smart” HTML

59. Walk Through: Logon Processing Submits to /struts-example/ Invokes ActionServlet processing Selects the correct <action> element: <action path=”/logon” type=”org.apache....LogonAction” name=”logonForm” scope=”session” input=”logon”/>

60. Walk Through: Logon Processing Instantiates logonForm bean if needed, per form bean definition: <form-bean name=”logonForm” type=”org.apache....DynaValidatorForm”> <form-property name=”username” type=”java.lang.String”/> <form-property name=”password” type=”java.lang.String”/> </form-bean>

61. Walk Through: Logon Processing Server-side validation is performed based on configured validation rules <form name=”logonForm”> <field property=”username” depends=”required,minlength,maxlength”> ... <field property=”password” ...> ... </form> In this case, we used client-side validation as well, via generated JavaScript You should never trust client-side validations to be enough ...

62. Walk Through: Logon Processing If validations fail, control goes to the “logon” forward <action path=”/logon” type=”org.apache....LogonAction” name=”logonForm” scope=”session” input=”logon”/> Which was defined to point at the logon page in a global forward definition <forward name=”logon” page=”/logon.jsp”/>

63. Walk Through: Logon Processing If validation succeeds, the execute() method of our configured Action class is invoked (“Command Pattern”) public class LogonAction extends Action { public ActionForward execute (ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { ... } }

64. Walk Through: Logon Processing The action checks the username and password against the user database ... On unsuccessful match, stores an error message and returns to the input page return (mapping.getInputForward()); On successful match, logs user in and indicates “success” return (mapping.findForward(“success”)); Which transfers to the main menu page <forward name=”success” page=”/mainMenu.jsp”/>

65. But What About Prepopulation? Often, you need to pre-populate fields to be displayed on a page The Edit Registration option illustrates a very typical Struts design pattern: “Setup” action populates beans (including the form bean), and forwards to ... Page that displays the populated form, and submits to ... “Process” action that updates the database based on the new user input values

66. Walk Through: Edit Registration Let's walk through the “Edit Registration” processing of the example application A little faster, now that we've got the hang of how Struts handles requests We start on the main menu (first link) <html:link page=”/editRegistration...”> <bean:message key=”mainMenu.registration”/> </html:link>

67. Walk Through: Edit Registration The “/editRegistration” action declares a form bean, but with no validation <action path=”/editRegistration” type=”...EditRegistrationAction” name=”registrationForm” scope=”request” validate=”false”/> So, Struts precreates an empty form bean, but does not trigger validation on it

68. Walk Through: Edit Registration The EditRegistrationAction's execute() method then: Ensures that there is a logged on user Copies the user's info to the form bean Sets a transaction token to disallow double submits (saveToken()) Forwards to the “success” logical forward For this action, we have a local override of “success” that selects “/registration.jsp” instead

69. Walk Through: Edit Registration The /registration.jsp page displays the form values, already filled out because of the setup Action's activity The form submission goes (after validation is completed) to the /saveRegistration action, which ... Updates the database Goes back to the main menu again You will see this three-step pattern over and over again in Struts-based applications

70. Example Application Summary We've seen the basic organization and features that Struts provides Struts lives up to its promise to separate the concerns of the presentation logic and the business logic But what about a bigger application? How do I organize things when I've got 50 pages instead of 5?

71. Next Steps Examine the architectural decisions required to design and build a web application Examine how these decisions were done in a more advanced Struts-based application But first ... let's take a quick break

73. Web Application Architecture Decisions

74. Overall Architecture Decisions Let's start by assuming we are going to use Struts to develop a fairly large application Good choice :-) Our required decisions follow the separations of the MVC paradigm Model Related Decisions Technology for persistence tier Technology for business logic Transporting data to presentation tier

75. Overall Architecture Decisions View Related Decisions Technology for markup generation Layout management strategy Form bean strategy Input validation strategy Localization strategy Controller Related Decisions Mapping logical names to physical resources Responsibility split between Actions and Business Logic

76. Development Process Decisions Maximize opportunities for concurrent development across tiers Identify required cross-tier knowledge transfers Strive to hide implementation details Application architect should own configuration file management Struts-config.xml tends to be a clearinghouse for cross-tier communication Can subdivide on functional lines if needed

77. Persistence Tier Technology In many cases, this decision will have already been made for you Creating new web-based interface to existing data or functionality In many cases, there will be more than once answer needed in the same app: Tables in existing relational databases User information in a directory server Connector to legacy applications

78. Persistence Tier Options Relational Database (RDBMS) Very common choice “Rows and columns” paradigm is well understood Mature, high performance products available Programmatic access, directly (JDBC) or indirectly (EJB, O-R mapping tiers, ...) Relational organization often needs to be adapted to O-O design patterns

79. Persistence Tier Options Object-Oriented Database (OODBMS) Persistent data directly reflects object oriented relationships Some databases implement this directly Others define and/or generate a mapping of objects onto RDBMS tables Relatively newer, less mature

80. Persistence Tier Options Flat Files Best for sequential-only access Can utilize text or binary data formats Text formats tend to be more flexible Binary formats tend to be more compact Common text-based formats One “row” per line with comma-separated columns (often called “CSV”) Extensible Markup Language (XML) Nice for hierarchical data Becoming popular for inteoperability

81. Persistence Tier Options Integration Connectors Often used to connect with legacy applications Typically implemented as a network based protocol accessing a remote application or service Web Services is about standarizing integration using XML data contents, described by WSDL metadata

82. Persistence Tier Decision Goals Define an API abstraction for use by business logic developers Independent of web tier, so can be reusable Presented in O-O terms for familiarity Functional content driven by business logic requirements

83. Persistence Tier Decision Goals Insulate business logic developers from changes in underlying environment Database Administrator splits tables Data source changes from flatfile to RDBMS or web service or EJB Data transport APIs for the presentation tier may be defined here Or in the business logic tier

84. Persistence Tier Decision Goals Support transactional capabilities of most persistence tier technologies Begin ... Process ... Commit/Rollback Supports “all or nothing” changes to avoid inconsistent state being stored Implementation details hidden inside defined APIs

85. Persistence Tier Decision Goals Support resource pooling to conserve scarce resources Connections to resources often scarce Allocating connection per user would limit scalability Implementation details hidden inside defined APIs

86. Business Logic Technology The functional behavior of your application Add new customer ABC Transfer $X from acct 123 to acct 456 Submit purchase order 789 Typically modelled as an individual Java method per use case Enables reuse across apps Improves unit testability

87. Business Logic Technology Should operate on persistence tier API abstractions, not directly on databases Insulated from changes in underlying persistence tier environment Allows business logic developers to focus on business problems, not database problems Should be independent of presentation tier considerations Data is locale-independent objects

88. Business Logic Technology Business logic can be stateful or stateless Stateful logic requires multiple interactions with the user to complete a single business transaction Stateless logic can be done in a single call Can sometimes model stateful logic as stateless if you use the persistence tier to maintain the state for you Business logic can be implemented in JavaBeans or EJB session beans

89. Business Logic Decision Goals Define an API abstraction for use by presentation logic developers Independent of web tier, so can be reusable Presented as method per use case, with imperative names Functional content driven by business logic requirements Data transport APIs for the presentation tier may be defined here Or in the persistence tier

90. Data Transport Strategy Presentation tier will require access to dynamic data to build user interfaces Dynamic data may originate in: Persistence tier Business logic tier Yet, we still want to insulate presentation tier developers from the underlying details The usual approach is to use the Data Transfer Object (nee Value Object) pattern

91. Data Transport Strategy Typical Java implementation of a DTO is a simple JavaBean with only properties: Properties are still native object types (to avoid ties to presentation tier) Objects are light weight and Serializable Supports type safety and compile-time checks on property getters and setters Tedious to create and maintain without tools support

92. Data Transport Strategy A less tedious approach is to use a java.util.Map to contain the values to be transported Objects are light weight and Serializable Avoids the need to create and maintain JavaBean classes for each DTO Loses type safety checks on property types Compiler cannot catch errors like typos in property names for you

93. Data Transport Strategy Struts (because it includes commons-beanutils) supports DynaBeans as a hybrid between these approaches Properties (name and type) belonging to a DynaBean can be configured programmatically Objects are light weight and Serializable Property getters and setters are typesafe, but name typos still not caught Interoperates with Struts presentation tags

94. Data Transport Decision Goals Consider tradeoffs of using JavaBeans versus more generic options Maintain independence of presentation tier considerations (date formats, etc.) Avoid use of EJB entity beans directly as data transport objects Potential network request on each property getter, versus once to retrieve entire DTO

95. Markup Generation Technology Decision starts with a description of the client runtime environment. Typically: Standard browser (usually HTML) With or without client-side JavaScript Standard browser with plugins (Macromedia Flash, Adobe Acrobat, SVG Viewer, Java Applets, ...) Rich client with programmatic capabilities (JavaWeb Start, client-server GUI, ...)

96. Markup Generation Technology Based on this, decide where actual markup will be generated: Server Side – Markup composed by server and displayed by the client (possibly with embedded scripting) Typical for HTML-based web apps Client Side – Server sends a high level description of the data to be presented, but client performs layout Flash, SVG Viewer, Xforms, ...

97. Markup Generation Technology Server side content can be dynamically generated via a number of technologies: Programmatic execution of a servlet JavaServer Pages (JSP) Alternative templating solutions (Velocity, FreeMarker, ...) Serialization of XML document objects Struts has extra support for JSPs used to render HTML on the server side, but can be used with other alternatives as well

98. Layout Management Strategy High quality user interfaces feature consistent look and feel across the entire application Traditional approach in web application design is “cut and paste” of common design elements across all pages Tedious and error prone Makes L&F remodels difficult

99. Layout Management Strategy Most markup generation technologies support composition of multiple elements: JSP: <jsp:include> and <%@ include %> Requires overall layout (i.e. the outermost <table>) to be present on each page Limits ability to adjust the overall layout dynamically (say, based on user preferences)

100. Layout Management Strategy Struts supports the Tiles Framework for advanced management of look and feel issues: Pages are assembled from a base layout that is separate from the actual pages Layout includes markers to include individual tiles by composition Individual tiles responsible for rendering only their individual portion of the overall content

101. Layout Management Strategy Tiles Framework supports many advanced features as well: Layouts can be defined in configuration files, individual JSP pages, or programatically Layouts can “extend” other layouts similar to the way Java subclasses extend superclasses Behavior of Tiles can be customized by passing attributes in a Tiles context.

102. Form Beans Strategy Users of interactive computer applications have been trained to expect common behaviors In particular, users expect the following when they make an error: A suitable error message will be shown The previous (incorrect) input values will be remembered, so the user need only correct their errors

103. Form Beans Strategy Aspects of HTTP and HTML make it difficult to meet this expectation: HTML input fields are strings, even for data types that might not be (date, int, ...) HTTP is stateless, and provides no facilities for remembering the previous values when a page is redisplayed To address this need, Struts defines an API for form beans (more formally, org.apache.struts.action.ActionForm)

104. Form Beans Strategy A form bean is a component of the presentation tier, and has two responsibilities: Represent server-side state of all the input fields on a form (even if the input data is syntactically or semantically invalid) Serve as a data transfer object (DTO) from the presentation tier to the business logic tier (via a Struts Action)

105. Form Beans Strategy Two general implementation strategies are available: Subclass ActionForm and add properties for each input field Leverage Struts support for DynaActionForms, and define the properties in the Struts configuration file Form bean instances are created as needed, typically in Request scope Session scope

106. Form Beans Recommendations Unless you have particular needs, use dynamic action forms Simpler to manage and maintain Do not include business logic directly in your form bean Data conversions belong in an Action Business logic belongs in separate classes that are part of the business logic tier

107. Form Beans Recommendations Declare the data type of all input field properties as Strings Exception: Checkboxes should be backed by a boolean property Reason: Consider what happens if you have a field of type “int” and the user types “1a3” instead of “123”: User expects validation error message and redisplay of “1a3” so it can be fixed User gets a runtime error because of the failed String->int conversion

108. Input Validation Strategy Robust applications will never allow incorrect values to be processed by the business logic tier, or stored in the persistence tier Each tier should protect itself from invalid input from client tiers Business logic might thrown IllegalArgumentException Persistence tier might throw SQLException because a database trigger detected a problem

109. Input Validation Strategy Correctness criteria come from multiple tiers of an application: Presentation tier: date and number formats Business logic tier: semantic requirements (minimum six characters in a password, email address is required) Presentation tier: unique key and foreign key constraints (that username belongs to someone else)

110. Input Validation Strategy High quality user interfaces perform input checking as close to the user as possible Per-field instead of per-form is typical In web applications, often implemented via client side JavaScript But you cannot trust clientside JavaScript to do everything for you It might be turned off It might be bypassed by a client application Cannot check 100% of requirements

111. Input Validation Strategy Struts offers the Validation Framework to manage combining correctness checks from all tiers into a configuration file Implemented rules are configurable (minimum # of characters) Set of available rules is extensible Correctness checks are triggered automatically where needed By form bean name By action path

112. Input Validation Strategy Correctness checks always performed on the server side Exception: normally disabled for “setup actions” Validation rules can optionally cause client side JavaScript to be generated that will perform checks before the form is submitted Improves user experience to catch these without a round trip to the server

113. Localization Strategy Providing a web application in multiple languages is becoming more common in a global economy Even if you don't think you need to support localization, you should do it anyway: You might be wrong :-) Mechanics of implementing this allow you to share things like prompt strings and button labels, even in a single language

114. Localization Strategy Struts supports localization at all levels <bean:message> tag looks up localized text from resource bundles Validation error messages are based on keys to look up localized text, with parametric replacement Can interoperate with JSTL for localized formatting Message resources can be used programmatically (localized log messages)

115. Logical To Physical Mapping Throughout our discussion on decisions, we have seen a need to isolate developers in one tier from implementation details in another tier Maintaining isolation minimizes the impact of changes inside one tier Struts provides multiple layers of support for this by mappings defined in the Struts configuration file

116. Logical To Physical Mapping Isolation is based on mapping a logical name for a resource to the physical implementation of that resource Action context-relative URL to Action class Form bean name to implementation class Exception to handler class Forward alias to context-relative URL Message resources bundle to implementation

117. Logical To Physical Mapping That being said, it is useful to define naming conventions that tie the various Struts features for a particular page together. We will see how this was done in the “Advanced” application example, soon

118. Actions and Business Logic Action classes are invoked by the Struts controller based on the request URL “Command Pattern” It is tempting to place business logic directly into Actions Common in smaller scale, simpler applications But this ties business logic to web APIs Yes, struts-example is guilty of this :-)

119. Actions and Business Logic Consider Actions part of the controller, not part of the model Extract incoming data from form bean Convert as necessary into DTOs defined by business logic tier “Adapter Pattern” Delegate processing to Business Logic class's appropriate business method Make DTOs needed by next page available Forward control to the next page

120. A More Advanced Struts Application

121. “Da Nooz” Example Application Even before blogging became popular ... Rich Site Summary (RSS) was a popular XML-based data format for syndication This application supports self registration and personal management of one or more RSS newsfeeds The RSS newsfeeds themselves are available in multiple formats The RSS “community” is fairly fractured

122. “Da Nooz” Example Application Based on Struts 1.1 Utilizes advanced features like the Tiles and Validator Frameworks Implements many “best practices” for web applications (with or without Struts) Illustrates specific architectural choices Not by any means the only reasonable ones Will be open sourced (probably at in the near future

123. Model Tier Decisions Persistence Choices Business Logic Choices Data Transport Object (DTO) Choices

124. Persistence Choices Original requirement for this demo included supporting multiple choices: Java Data Objects (JDO) Relational Database (JDBC) Flat File (Xml) Entity Beans (EJB) – not done yet Designed persistence tier API to reflect the natural object hierarchy: User –> Channel –> Item

125. Persistence – Basic Decisions Employ Data Access Object (DAO) pattern Support transactional state inside DAO JavaBeans oriented API to express characteristics of business entities Object oriented API to express relationships between business entities

126. Persistence–Implementation Independence JavaBeans style interfaces for each entity: User ( Channel ( Item ( Specific implementations of these interfaces depend on persistence strategy Business logic programmed in terms of interfaces, not implementations DAO interface (

127. Persistence–DAO Interface Transaction Lifecycle Methods: begin(), close(), commit(), isActive(), isClosed(), rollback() Top Level Application Methods: createUser(), findUser(), findUsers() Is it reasonable to separate these concepts? Absolutely! Tradeoffs always exist

128. Persistence–DAOFactory Interface In a web environment, it is important to minimize the amount of time resources are reserved for a specific user: Holding precious resources across requests is not a scalable strategy Connection pools are the usual mechanism for dealing with this issue But acquiring and releasing connections from a pool can be error prone Answer: provide higher level management

129. Persistence–DAOFactory Interface From an API perspective, very simple: public DAO getDAO() Implementation perspective – very useful: Provide DAO instances for short lived (typically single transaction) requirements Business logic using DAO does not have to worry about error conditions causing resource leakage Allocated resources freed when DAO instance is finished

130. Persistence–DAOFactory Selection In the “Da Nooz” application, DAOFactory implementation selection is a configuration option: Application assember picks a “listener” to run at startup time Listener makes an implementation available as a servlet context attribute Application uses generic DAO interface Implementation selection can be deferred to container configuration time

131. Persistence–DAOFactory Operation DAOFactory implementation is a servlet context attribute For each request, a Filter asks DAOFactory for a DAO for this request The Filter does not know or care about the actual DAOFactory implemetnation! The Filter cleans up (by closing the DAO), even if the application throws an exception

132. Persistence — JDBC Implementation JdbcDAOFactory – hands out DAOs Requires a javax.sql.DataSource to handle connection pooling Example code uses a JNDI resource for this JdbcDAO – instance per request Connection not allocated until begin() is called (if request doesn't need one) Connection returned to pool (if used) when close() is called (by DAOFilter in a web application environment)

133. Persistence – JDBC Implementation JdbcHandler – Programming queries directly with JDBC is tedious Get connection, get statement, get result set, process each row, close all objects JdbcDAO offers an easy-to-use query() method to hide all this complexity Takes SELECT statement, parameters, and JdbcHandler instance Handler called once per selected row Hollywood Principle -- “Don't call us, we'll call you”

134. Persistence – JDBC Implementation JdbcUser, JdbcChannel, JdbcItem Implementation specific persistent objects findXxx() contains embedded SQL for SELECT remove() contains embedded SQL for DELETE save() contains embedded SQL for INSERT or UPDATE For database independence, some people abstract SQL statements to properties file

135. Persistence–Decision Results Persistence tier supplies a “persistence independent” API to business logic tier Persistence tier is independent of view tier implementation technology No ties to Struts Framework APIs! Changes to persistence implementation details hidden inside an abstract API Business tier is “mostly” independent of persistence tier implementation decisions

136. Business Logic Choices Business logic for “Da Nooz” is very simple Encapsulated as methods on a single class ( Each method accepts parameters: DAO for the current request Primary keys (as necessary) DTO containing name/value pairs

137. Data Transfer Object Choices Persistence layer exposes User, Channel, and Item as abstractions of the underlying persistent data Business logic expects java.util.Map parameters for name/value pairs: Avoids linkage to Struts APIs that would lock it to web app use only Could have used DynaBean directly BeanUtils.copyProperties() useful for bulk transfer of name/value pairs w/conversion

138. View Tier Decisions Technology for markup generation Layout management strategy Form bean strategy Input validation strategy Localization strategy

139. View Tier – Markup Generation Chose to use JavaServer Pages Popular, well understood, widely deployed Struts tag libraries support this platform JSP Standard Tag Library (JSTL) Used in RSS rendering for access to EL Struts offers a struts-el tag library that supports EL evaluation on JSP 1.2 containers JSP 2.0 will support EL evaluation everywhere

140. View Tier – XML Markup “Da Nooz” normally renders HTML for the user's management activities It also has facilities to directly create RSS feeds directly, in multiple formats This is done using a JSP page as a template: /rss/version-0_91.jsp /rss/version-1_0.jsp Templates pull data with JSTL tags

141. View Tier – Layout Management Chose to use Tiles Framework <definition name=”.layout.basic” page=”/layout/basic.jsp”> <put name=”title” value=”Da Nooz”/> <put name=”header” value=”/tiles/header.jsp”/> <put name=”footer” value=”/tiles/footer.jsp”/> <put name=”menu” value=”/tiles/blank-menu.jsp”/> <put name=”body” value=”/tiles/blank-body.jsp”/> </definition>

142. View Tier – Layout Management Actual formatting is in “/layout/basic.jsp” <table width=”800” class=”basic-background”> <tr><td colspan=”2” class=”basic-header”> <tiles:insert attribute=”header”/> </td></tr> <tr><td width=”20%” class=”basic-menu”> <tiles:insert attribute=”menu”/></td> <td width=”80%” class=”basic-body”> <tiles:insert attribute=”body”/></td> </tr> <tr><td colspan=”2” class=”basic-footer”> <tiles:insert attribute=”footer”/ </td></tr> </table>

143. View Tier – Layout Management Tiles can extend previous definitions <definition name=”.layout.loggedon” extends=”.layout.basic”> <put name=”menu” value=”/tiles/loggedon-menu.jsp”/> </definition> <definition name=”.menu” extends=”.layout.loggedon”> <put name=”title” value=”Main Menu”/> <put name=”body” value=”/pages/menu.jsp”/> </definition>

144. View Tier – Layout Management Individual pages (/pages/menu.jsp) provide only the content for their tile Concept is very similar to how portal servers aggregate content from multiple portlets Can easily create portals with Tiles

145. View Tier – Form Beans DynaBeans avoid need to create separate classes for each form (and tie validation rules in as well): <form-bean name=”logonForm” type=”o.a.s.v.DynaValidatorForm”> <form-property name=”username” type=”java.lang.String”/> <form-property name=”password” type=”java.lang.String”/> ... </form-bean>

146. View Tier – Input Validation Struts utilizes the commons-validator framework to support validation on input form fields Validation checks always performed on the server side, before control passes to your Action Framework can optionally generate client-side JavaScript for some or all of the tests

147. View Tier – Input Validation Validation rules described in a config file: <form name=”logonForm”> <field property=”username” depends=”required,minlength,maxlength”> ... <field property=”password” ...> ... </form>

148. View Tier – Input Validation Matched by name to fields in the form: <html:form action=”/logon/process” ...> ... <html:text property=”username” .../> ... <html:password property=”password” ...> ... </form>

149. View Tier – Input Validation Client-side tests are easily incorporated <html:form action=”/logon/process” ... onsubmit=”return validateLogonForm(this)”> ... </form> <html:javascript formName=”logonForm” .../>

150. View Tier – Localization All of the prompts and messages in “Da Nooz” are localizable Tag in JSP page specifies a message key <bean:message key=”common.prompt.username”/> Message text is defined in an application properties files (Resource Bundles) common.prompt.username = Username: Character Encoding set to “UTF-8” <%@ page contentType=”text/html;charset=”UTF-8” %>

151. View Tier – Localization Actions can localize messages too: public class MyAction ... { public void execute(...) { ... Locale locale = request.getLocale(); MessageResources messages = getResources(request); String message = messages.getMessage(locale, “the.key”); throw new FooException(message); ... } }

152. Controller Tier Decisions Mapping logical names to physical resources REST-ful URLs for RSS feeds

153. Controller – Name Mapping As we have seen, the Struts configuration files can isolate the “logical” names for various resources from their “physical” name or location Nevertheless, it is convenient, when initially developing an application, to establish a standardized logical naming strategy Consider the “channel” page that displays a particular channel's information

154. Controller – Name Mapping Model Tier Concepts for Channel: – Persistence tier interface – Persistence tier implementation of type Xxx

155. Controller – Name Mapping View Tier Concepts for Channel: channel – Name of global <forward> .channel – Name of tile definition /pages/channel.jsp – Path to JSP page for body tile (context relative) ChannelForm – Name of form bean (and key to validation rules) channel.xxxxx – Localizable message strings specific to this form

156. Controller – Name Mapping Controller Tier Concepts for Channel: /channel/setup – Action path for “setup” action, which will forward to the view tier page /channel/process – Action path for “process” action, which will perform the required transaction The details of your conventions are not as important as having them, so that logical names are more predictable

157. Controller – REST-ful URLs Proponents of the Representational State Transfer (REST) view of web architecture suggest that all resources have meaningful and persistent URLs We have seen that Struts de-emphasizes this, because the URL seen by the user is normally the action they last submitted to The RSS feeds created by “Da Nooz”, though, should have such URLs if possible

158. Controller – REST-ful URLs Using standard Struts facilities, the URL would need to include the action path of the setup action (/nooz/ What we would like is something easier to remember: &channelname=main

159. Controller – REST-ful URLs How can this be accomplished? Web server redirect directives Separate servlet mapped to “/rss” Filter that forwards requests for “/rss” to “/nooz/” inside the web application (Servlet 2.3 or later) The third technique was employed in “Da Nooz”, and is generally applicable whenever you need REST-ful URLs in a Struts based application

160. Controller – REST-ful URLs Filters can chain or forward: public class ForwardingFilter implements Filter { public void doFilter(...) { ... if (is-mappable-request-url?) { RequestDispatcher rd = ...; rd.forward(request, response); } else { chain.doFilter(request, response); } } }

161. Struts and JavaServer Faces

162. Struts and JavaServer Faces JavaServer Faces isa new API undergoing standardization as JSR-127 in the Java Community Process Currently in Public Draft 2 State EA4 release of reference implementation available as part of the Java Web Services Developer Pack 1.2 Plan is to go final by the end of this year I am co-spec-lead on the JSR

163. Struts and JavaServer Faces JavaServer Faces is a server side UI component framework for Java web apps So there are overlaps in functionality with the Struts features discussed today JSP tags for rendering (Struts HTML library) Concept of managing separation of presentation and business logic in configuration files Indeed, Struts has had impact on how JavaServer Faces approaches many issues

164. Struts and JavaServer Faces JavaServer Faces has some unique capabilities that Struts does not have: Rendering API that is independent of JSP Rendering API that is independent of HTML Likewise, Struts has some unique capabilities that JavaServer Faces does not have: Tiles Framework Validator Framework

165. Struts and JavaServer Faces So, is JavaServer Faces going to standardize Struts out of existence? Absolutely not! Well then, can I use the technologies together? For sure! How can I do that? I'm glad you asked ...

166. Struts and JavaServer Faces If you have existing applications (and/or expertise) based on Struts, you can treat JavaServer Faces as an alternative view tier component library Thus, maintaining your investment in the controller and model tiers An integration library has been developed to make this very easy Available on the Struts web site

167. Struts and JavaServer Faces Design goal of the integration library Allow you to take an existing Struts app Migrate your JSP pages from the Struts HTML tags to JavaServer Faces tags One page at a time ... And not have to touch your Actions or business logic This goal has been achieved. Proof of concept is a converted struts-example that uses the new component capabilities

168. Struts and JavaServer Faces That being said, you can use JavaServer Faces directly and achieve many of the “separation of concerns” benefits that Struts provides The “jsf-pure” demonstration is the same application converted to be based solely on JavaServer Faces So, this should trigger some interesting innovation in future versions of Struts Now that 1.1 is done, we can go for it

169. Summary

170. Summary We have covered a lot of ground ... Background technologies Basics of Struts features Architectural decisions when designing large scale applications Implementation of those decisions in a more advanced Struts demo app A brief look at a future technology that will be affecting Struts

171. Summary It should be clear by now that Struts is a mature, stable technology base for designing and building scalable, maintainable web applications Roughly 75,000 downloads per month There are many web and print resources to provide more information, and much expertise in Struts available

172. Summary The STRUTS-USER mailing list in particular is very helpful to beginners who are learing to use Struts capabilities Over 2700 subscribers (largest user list at Friendly atmosphere Most Struts developers hang out here too Good luck with your current and future use of Struts!

173. Information Resources

174. Resources Struts Main Web Site: Struts Resources Pages: Struts-Faces Integration Library jakarta-struts/release/struts-faces/ Java Web Services Developer Pack

175. Resources HTTP/1.1 Specification HTTP BASIC and DIGEST Authentication HTML/4.01 Specification Cascading Style Sheets Level 2 Specification

176. Resources Cross Site Scripting Vulnerabilities: /malicious_code_mitigation.html

177. Resources XML/1.0 (Second Edition) Specification XML Namespaces Specification XML Information Set Specification XML Base Specification:

178. Resources Associating Stylesheets With XML Docs XSL Transformations (XSLT) Specification XML Path Language (Xpath) Specification Web Content Accessibility Guidelines

179. Resources ECMAScript Language Specification (3rd Edition) http:/

180. Resources Java Language Tutorial Java Web Services Tutorial Useful chapters on all the relevant Java APIs and technologies! Servlets JavaServer Pages:

181. Resources JSP Standard Tag Library (JSTL) JavaServer Faces

  • Login