1 / 63

Introduction to the Jakarta Struts Framework

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. JavaServer Pages (JSP). A JSP file is a java servlet.

beau-randall
Download Presentation

Introduction to the Jakarta Struts Framework

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. • It’s 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 doesn’t 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 don’t want to see HTML tags in java code, we don’t 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: <form:form action="join.do" focus="email" > <form:text property="email" size="30" maxlength="30"/> <form:submit property="submit" value="Submit"/> </form:form>

  14. JSP Tags • Resulting HTML sent to the browser: <form name="joinForm" method="POST“ action="join.do;jsessionid=ndj71hjo01"> <input type="text" name="email" maxlength="30" size="30" value=""> <input type="submit" name="submit" value="Submit"> </form> <script language="JavaScript"> <!-- document.joinForm.email.focus() // --> </script>

  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 don’t 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.setFname(). • 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 couldn’t 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).

More Related