Struts Introduction Course

Editor's Notes

• #6: Part of what needs to be understood at this point is the history of how this evolved. First, Servlets were created, and Java programmers said this is a good thing. Servlets are faster and more powerful than standard CGI, are portable, and infinitely extensible. However, everything wasn’t perfect. The Java programmer had to programmatically create HTML from within their Servlets. This of course was tiresome and problematic. So Java Server Pages were created, and Java programmers said this is a good thing. As with anything new and wonderful, JSP’s were misused. Too much code was put into the JSP. Some discipline was needed. In the object-oriented programming world, discipline is defined as design patterns. Using the JSP for the view component and Servlets as the controller component was deemed to be the appropriate approach. Thus, using the MVC design pattern was adopted. Note that the MVC design pattern had been around for a while in other object-oriented languages. The Struts project was launched in May 2000 by Craig R. McClanahan to provide a standard MVC framework to the Java community. In July 2001, Struts 1.0 was released.
• #7: A user sitting at a browser clicks a button, link, or types in a url. A Struts Servlet receives that request. It normally hands over the request to a FormAction class. The FormAction class is responsible for validating any form input. Control is then passed on to an Action class. It’s the responsibility of the Action class to call any Model components, such as classes responsible for updating information in a database. The final step is typically to forward to another JSP, thus a response being sent back to the browser.
• #8: The default Servlet controller is org.apache.struts.action.ActionServlet. This Servlet can be extended by your application, but typically there is no need to. Note that this ONE Servlet controls all of your Struts application. Your application will consist of any number of Java Server Pages. These pages could be list pages, form pages, or any other type of web page. Your application will normally consist of other classes that make up the Model components. These classes can be either standard Java classes of EJB’s, or a combination of both.
• #9: In using WSAD and Struts, you’ll notice that once you start your application, the web.xml file is read, loads the ActionServlet, which then reads the struts-config.xml file, which has references to all of your form beans (ActionForms), Action beans, and the navigation your application will use.
• #10: Many requirements documents used for building web applications focus on the View. However, you should ensure that the processing required for each submitted request is also clearly defined from the Model's perspective. In general, the developer of the Model components will be focusing on the creation of JavaBeans classes that support all of the functional requirements. The precise nature of the beans required by a particular application will vary widely depending on those requirements, but they can generally be classified into several categories.
• #11: EJB’s are the industry standard for Java Model components. With that said, you’ll find that you don’t always use them. There is nothing to prevent you from connecting to a database, performing a SQL statement, and then returning the result set from any type of Java class. In grammatical terms, we might think about state information as nouns (things) and actions as verbs (changes to the state of those things).
• #12: Within a web-based application, JavaBeans can be stored in (and accessed from) a number of different collections of "attributes". Each collection has different rules for the lifetime of that collection, and the visibility of the beans stored there. Together, the rules defining lifetime and visibility are called the scope of those beans. The Java Server Pages (JSP) Specification defines scope choices using the above terms (with the equivalent Servlet API concept defined in parentheses):
• #13: You should note that a "form", in the sense discussed here, does not necessarily correspond to a single JSP page in the user interface. It is common in many applications to have a "form" (from the user's perspective) that extends over multiple pages. Think, for example, of the wizard style user interface that is commonly used when installing new applications. Struts encourages you to define a single ActionForm bean that contains properties for all of the fields, no matter which page the field is actually displayed on. Likewise, the various pages of the same form should all be submitted to the same Action Class. If you follow these suggestions, the page designers can rearrange the fields among the various pages, often without requiring changes to the processing logic.
• #14: Although business logic should not be directly included in the ActionForm class, it is a good idea to call Java Beans or Enterprise Java Beans that contain the business logic from your ActionForm. If an error is then identified by calling the business logic, an ActionError can easily be generated.
• #15: When defining your getter and setter methods, make sure the names match with what were specified within the form on the Java Server Page. For example, if you defined a text field within your form named firstName, you should define a private String property with a getFirstName() and setFirstName() methods.
• #16: For small scale systems, or for state information that need not be kept for a long period of time, a set of system state beans may contain all the knowledge that the system ever has of these particular details. Or, as is often the case, the system state beans will represent information that is stored permanently in some external database (such as a CustomerBean object that corresponds to a particular row in the CUSTOMERS table), and are created or removed from the server's memory as needed. Entity Enterprise JavaBeans are also used for this purpose in large scale applications.
• #17: When writing business logic beans, there should never be any reference to resources that are only available within a web application server environment. It would NOT be a good idea to pass something like the HttpServletRequest block to a business logic bean. This would limit the use of that business logic bean to only be used within a web project. The idea is to have the business logic bean available to ANY type of application.
• #18: One of the reasons to place business logic into an EJB is for scalability. If a particular business logic bean was referenced in numerous applications as a regular Java Bean, this would take additional resources. If that business logic is written within an EJB, it would only be instantiated once.
• #19: Although Struts provides a mechanism within the struts-config.xml file to define data sources, WebSphere provides a similar mechanism which also includes a more sophisticated connection pool.
• #20: This unit focuses on the task of building the View components of the application, which will primarily be created using Java Server Pages (JSP) technology. In particular, Struts provides support for building internationalized applications, as well as for interacting with input forms.
• #21: With the use of a property files, Struts has the capability to handle multiple languages. Instead of placing text directly within your Java Server Pages, a Struts bean tag is used to get that information from a property file. If for example you need to also support Spanish, a second property file would be defined with the same name as the original with an “_es” appended to the name. This property file would have the Spanish text. The browser recognizes what language the user has set for their default, and Struts uses that to know which property file to reference.
• #22: When you configure the controller Servlet in the web application deployment descriptor, one of the things you will need to define in an initialization parameter is the base name of the resource bundle for the application. <servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>application</param-name> <param-value>MyResources</param-value> </init-param> <.../> </servlet>
• #23: At one time or another, most web developers have built forms using the standard capabilities of HTML, such as the <input> tag. Users have come to expect interactive applications to have certain behaviors, and one of these expectations relates to error handling -- if the user makes an error, the application should allow them to fix just what needs to be changed -- without having to re-enter any of the rest of the information on the current page or form. Fulfilling this expectation is tedious and cumbersome when coding with standard HTML and JSP pages. For example, an input element for a username field might look like this (in JSP): <input type="text" name="username" value="<%= loginBean.getUsername() %>"/> which is difficult to type correctly, confuses HTML developers who are not knowledgeable about programming concepts, and can cause problems with HTML editors. Instead, Struts provides a comprehensive facility for building forms, based on the Custom Tag Library facility of JSP 1.1. The case above would be rendered like this using Struts: <html:text property="username"/> with no need to explicitly refer to the JavaBean from which the initial value is retrieved. That is handled automatically by the framework. HTML forms are sometimes used to upload other files. Most browsers support this through a <input type="file"> element, that generates a file browse button, but it's up to the developer to handle the incoming files. Struts handles these "multipart" forms in a way identical to building normal forms.
• #24: Notice line 2 and 3. These reference the Struts tag libraries. A tag library ends with a “.tld” extension. Struts has several tag libraries that you’ll end up using. This section of a JSP is only referencing the Struts html and bean tag libraries. Notice the prefix, and then how that prefix is used to reference a text field for example.
• #25: The tag libraries should first be referenced within the web.xml file. The taglib directive within the Java Server Page typically references the uri specified within the web.xml file. There are two ways to use the error tags. You can have one place within your Java Server Page to show all errors, or you can place an error tag close to each field that may result in an error condition. These error conditions are created within your ActionForm class.
• #26: Within the <form-beans> section in the struts-config.xml file, you would define a form tag like the following: <form-bean name="CustomerFormBean" type="com.pri.javaTraining.CustomerForm" /> This <form-bean> tag is also referenced within the <action-mappings> tag in the struts-config.xml file, like the following: <action path="/CustomerAction" type="com.pri.javaTraining.CustomerAction" name="CustomerFormBean" scope="request" input="/pgcustomer.jsp"> <forward name="Save" path="/pgindex.jsp"/> <forward name="Add Account" path="/pgaddaccount.jsp"/> <forward name="Cancel" path="/pgindex.jsp"/> </action>
• #27: In every case, a field tag must be nested within a form tag, so that the field knows what bean to use for initializing displayed values. The form "field" tags in the Struts-HTML tag library share a common set of tag attributes that have the same meaning, no matter what field tag they are used with. These properties also accept Runtime Expressions, meaning you can set them with a scriptlet.
• #28: Below is an example of using both the <logic:present> and <logic:iterate> tags. The <logic:present> tag in this example checks for a value from the SessionBean object by calling the getCurrentCustomerAccounts() method. This is done automatically by placing a reference of “CustSessionBean” which points to the <jsp:useBean> tag, which references the SessionBean class within the session block. The property attribute is then used to look for the method with a “get” and the same name as what is specified within the property attribute, with the first character being uppercase. The example below also demonstrates the use of the <iterate> tag. This is one of the most useful tags within Struts. This tag is also using the SessionBean object mentioned above. It also is calling the same getCurrentCustomerAccounts() method. This method returns a class that is within the Collection family of classes. In this particular example, it is using a Vector. The Vector was loaded with a class named CheckingAccount. The CheckingAccount class has the following methods: getAccountNo(), getAccountTypeString(), getStatusCode(), getBalance(), and getOpenDateFormatted(). Notice on the <logic:iterate> tag the id attribute is named “aAccount”. This is then referenced within the <bean:write> tag by specifying a name attribute with the same value. The property attribute within the <bean:write> tag is used to call the appropriate method on whatever class that is within the Vector (or other Collection type class). <jsp:useBean id="CustSessionBean" scope="session" class="com.pri.javaTraining.SessionBean"/> <logic:present name="CustSessionBean" property="currentCustomerAccounts"> <logic:iterate id="aAccount" name="CustSessionBean" property="currentCustomerAccounts"> <TR> <TD><bean:write name="aAccount" property="accountNo"/></TD> <TD><bean:write name="aAccount" property="accountTypeString"/></TD> <TD><bean:write name="aAccount" property="statusCode"/></TD> <TD><bean:write name="aAccount" property="balance"/></TD> <TD><bean:write name="aAccount" property="openDateFormatted"/> </TR> </logic:iterate> </logic:present>
• #29: It is a good idea to use the Struts tags instead of the plain HTML tags. Some of these tags may not provide much additional capabilities, but they can be extended. If extended, you can provide whatever additional capabilities you need.
• #30: The validate() method has the following options: Perform the appropriate validations and find no problems -- Return either null or a zero-length ActionErrors instance, and the controller servlet will proceed to call the perform() method of the appropriate Action class. Perform the appropriate validations and find problems -- Return an ActionErrors instance containing ActionError's, which are classes that contain the error message keys (into the application's MessageResources bundle) that should be displayed. The controller servlet will store this array as a request attribute suitable for use by the <html:errors> tag, and will forward control back to the input form (identified by the input property for this ActionMapping). As mentioned earlier, this feature is entirely optional. The default implementation of the validate() method returns null, and the controller servlet will assume that any required validation is done by the action class. One common approach is to perform simple, prima facia validations using the ActionForm validate() method, and then handle the "business logic" validation from the Action.
• #31: Another approach to this would be to use the Struts Template Tag library.
• #32: When creating a browser based application, it is typical to have some type of common navigation on each Java Server Page. One of the easiest approaches to providing this is by placing the common navigation into a file that is later included in the specific Java Server Page.
• #33: The Controller portion of the application is focused on receiving requests from the client (typically a user running a web browser), deciding what business logic function is to be performed, and then delegating responsibility for producing the next phase of the user interface to an appropriate View component. In Struts, the primary component of the Controller is a servlet of class ActionServlet. This servlet is configured by defining a set of ActionMappings. An ActionMapping defines a path that is matched against the request URI of the incoming request, and usually specifies the fully qualified class name of an Action class. All Actions are subclassed from org.apache.struts.action.Action. Actions encapsulate the business logic, interpret the outcome, and ultimately dispatch control to the appropriate View component to create the response.
• #34: org.apache.struts.action.ActionServlet is the default Servlet that is provided with Struts. This Servlet can be used, or it can be extended. If extended, the extended version should be defined in the web.xml file. For smaller applications, ActionServlet typically provides the necessary functionality. For larger applications, it is typically extended.
• #35: It is not always necessary to create an Action class for each form within your project. For smaller applications one Action class could provide the necessary functionality for the entire project. However, it is a good practice to create a new Action class for each form. So for a Java Server Page that has a form, an extension of the ActionForm class would be created, and an extension of the Action class would also be created. This allows for easier maintenance. It is also a widely adopted approach within the Struts development community to place a form on EVERY Java Server Page. Even list pages would have a form defined on them. This gives the maximum flexibility to the developer. This approach allows for more flexibility on navigation.
• #36: The second method is the one used by WebSphere.
• #37: If is NOT a good practice to “hard code” the name of the Java Server Page that you are forwarding to. Within Struts all Java Server Pages should be specified within the struts-config.xml file. For a particular Action class, multiple forward tags may be specified. Here’s an example: <action path="/CustomerAction" type="com.pri.javaTraining.CustomerAction" name="CustomerFormBean" scope="request" input="/pgcustomer.jsp"> <forward name="Save" path="/pgindex.jsp"/> <forward name="Add Account" path="/pgaddaccount.jsp"/> <forward name="Cancel" path="/pgindex.jsp"/>
• #38: Below is a very simple example of an Action class’ perform method: public ActionForward perform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { /** Get a handle to the StrutsInputForm */ StrutsInputForm strutsForm = (StrutsInputForm) form; /** Get the action from the form */ String action = strutsForm.getAction(); /** Forward control to the specified success URI */ return (mapping.findForward(action)); }
• #39: Only define variables within the perform() method, or within methods that you’ve added to the Action class.
• #40: A common approach to logging is to use another of the Jakarta open source modules named Log4j: http://jakarta.apache.org/log4j/docs/index.html
• #41: Below is an example of an ActionMapping implementation: <action path="/CustomerAction" type="com.pri.javaTraining.CustomerAction" name="CustomerFormBean" scope="request" input="/pgcustomer.jsp"> <forward name="Save" path="/pgindex.jsp"/> <forward name="Add Account" path="/pgaddaccount.jsp"/> <forward name="Cancel" path="/pgindex.jsp"/>
• #42: The two important elements are: <form-beans>This section contains your form bean definitions. You use a <form-bean> element for each form bean, which has the following important attributes: name: A unique identifier for this bean, which will be used to reference it in corresponding action mappings. Usually, this is also the name of the request or session attribute under which this form bean will be stored. type: The fully-qualified Java classname of your form bean. <action-mappings>This section contains your action definitions. You use an <action> element for each of your actions you would like to define. Each action element requires the following attributes to be defined: path: The application context-relative path to the action type: The fully qualified java classname of your Action class name: The name of your <form-bean> element to use with this action
• #43: Below is an example of a typical <form-beans> section: <form-beans> <!-- Struts Example form bean --> <form-bean name="StrutsInputFormBean" type="org.struts.example.StrutsInputForm" /> <form-bean name="StrutsDisplayFormBean" type="org.struts.example.StrutsDisplayForm" /> </form-beans>
• #44: Below is an example of a typical <action-mappings> section: <action-mappings> <!-- StrutsExample --> <action path="/StrutsInputPath" type="org.struts.example.StrutsInputAction" name="StrutsInputFormBean" scope="request" input="/PgInput.jsp"> <forward name="Next" path="/PgDisplay.jsp"/> </action> <action path="/StrutsDisplayPath" type="org.struts.example.StrutsDisplayAction" name="StrutsDisplayFormBean" scope="request" input="/PgDisplay.jsp"> </action> </action-mappings>
• #45: This is a section that will probably NOT be used when running an application server such as WebSphere. WebSphere has a much more sophisticated connection pooling mechanism.
• #46: We’re going to go over both the struts-config.xml and the web.xml files in later chapters.
• #47: You can find links to each tag library at the following URL under the Developer’s Guide: http://jakarta.apache.org/struts/doc-1.0.2/index.html. When developing Java Server Pages, a developer has the capability to imbed Java code. However, this is considered a bad approach. Through the use of the Struts tag libraries, and custom tag libraries, a developer should be able to create Java Server Pages without ANY Java code imbedded. Actually a widely accepted practice is to have a Business Analyst with web page design experience to create the Java Server Page. Once they have the “look and feel” completed, they would turn that Java Server Page over to the developer, who would add whatever additional capabilities that were necessary.
• #48: There are currently four taglibs that Struts is packaged with. The struts-bean taglib contains tags useful in accessing beans and their properties, as well as defining new beans (based on these accesses) that are accessible to the remainder of the page via scripting variables and page scope attributes. Convenient mechanisms to create new beans based on the value of request cookies, headers, and parameters are also provided. The struts-html taglib contains tags used to create struts input forms, as well as other tags generally useful in the creation of HTML-based user interfaces. The struts-logic taglib contains tags that are useful in managing conditional generation of output text, looping over object collections for repetitive generation of output text, and application flow management. The struts-template taglib contains tags that define a template mechanism.
• #49: About the form tag The Struts form tag outputs a standard HTML form tag, and also links the input form with a JavaBean subclassed from the Struts ActionForm object (see Javadoc). Each field in the form should correspond to a property of the form's bean. When a field and property correspond, the bean is first used to populate the form, and then to store the user's input when the form is submitted to the controller servlet. The name of the bean and its class can be specified as a property to the form tag, but may also be omitted. If omitted, the ActionMappings database (loaded from the struts-config.xml file) is consulted. If the current page is specified as the input property for an action, the name of the action is used. The type property for the bean is also then taken from the configuration, via a Form Bean definition.
• #50: Each of these would typically be prefixed with <html:. The Struts web site goes into detail about each tag: http://jakarta.apache.org/struts/api/org/apache/struts/taglib/html/package-summary.html#package_description
• #51: One important item to point out about HTML is that the developer has no control over the HTML tags. They only serve very specific purposes. The developer has to develop within those limitations. One of the major advantages of using tab libraries is that you’re NOT constrained with those limitations.
• #52: Notice the <html:text tag. It’s similar to the <input type=“text” html tag. One major difference is the property attribute, and this is important. The name you specify in the property tag, is what Struts uses to know which getter and setter methods to call. For example, if the property name is “state”, the getter method would be getState(), and the setter method would be setState. If a property name was “firstName”, the getter method would be getFirstName(), and the setter method would be setFirstName().
• #53: Much of the power of JavaServer Pages (JSP) technology comes from the simple and powerful mechanisms by which the servlet that is generated automatically from your JSP source page can interact with JavaBeans that represent the computational state of your application. In standard JSP pages, the <jsp:useBean> tag is used create a bean (if necessary), as well as a "scripting variable" that can be used within scriptlets to refer to these beans.
• #54: Two of the above tags that you’ll use frequently are the “message” and “write” tags. You use the “message” tag to retrieve text messages from the application resources file (whatever.properties). The “write” tag is used to display information that has either been entered or been retrieved from a database.
• #55: This JSP shows the use of the bean message and bean write tags. On the bean message tag, you specify a key name. This key name references an entry into your application resources file. On the bean write tag, you specify a name attribute which references the id of the iterate tag. You also specify a property name which references a getter method on the form bean that’s referenced by the “ImageLocationListForm”.
• #56: One question that may come up at this point is why not just put Java code into your JSP? The answer to that question is answered by referring back to the roles we’ve defined for doing this kind of development. The idea is to have someone that is not a programmer be able to create and maintain the JSP’s. This allows someone that has creative skills to create attractive and easy to use web pages. This also frees up the developer from what they normally consider tedious and time consuming tasks.
• #57: For further information on the Logic Tags, visit: http://jakarta.apache.org/struts/api/org/apache/struts/taglib/logic/package-summary.html#package_description
• #58: Many of the tags in this tag library will throw a JspException at runtime when they are utilized incorrectly (such as when you specify an invalid combination of tag attributes). JSP allows you to declare an "error page" in the <%@ page %> directive. If you wish to process the actual exception that caused the problem, it is passed to the error page as a request attribute under key org.apache.struts.action.EXCEPTION.
• #59: For further information on the Logic Tags, visit: http://jakarta.apache.org/struts/api/org/apache/struts/taglib/logic/package-summary.html#package_description
• #60: Notice the <logic:notEqual tag. It has a property attribute that references a getter method, a name attribute that references a form, and a value attribute that is what is going to be checked for a not equal condition. If the value is not equal to “Insert” in this example, the next line will be shown. The next line uses the bean message tag, and will display a title indicating this is a Detail page. Also notice the closing </logic:notEqual> tag. The next line shows a <logic:equal tag. If the value does equal “Insert”, a title of “Insert” is displayed. By using this approach we were able to use the same JSP for both a page to perform updates to existing data, and the capability to insert new records.
• #61: The Template library supplies tags that are useful for creating dynamic JSP templates for pages which share a common format.
• #62: For further information on Template Tags, visit: http://jakarta.apache.org/struts/api/org/apache/struts/taglib/template/package-summary.html#package_description
• #63: This JSP shows the use of custom tags. Note the <broker:form> tag. This tag has other customer tags nested within it. The purpose of this link tag is to take the values of the attributes passed to it, along with the values of the other custom tags nested within it, and create an XML document that can be passed to another web server. It actually encrypts the XML document, and embeds that data within a form with a submit button. The user is then able to click the button or link and they’re directed to one of the image servers, and an image is displayed. Below is the html source from what gets generated from the custom tags above: <form name="ibs_form5" method="POST" action="http://corpiisimgdv01.pri.corpad.net/devibroker/broker_process.asp" target="_blank"> <a href=javascript:document.forms.ibs_form5.submit()>EOBs/REMITS (via Doc Handle)</a><br> <input type="hidden" name="packet" value="E25A7C35ECBD975BCBCBED16C10EB6BE9343A40B022DC2FF774ABAD53D94293FB1780D4D4D9489B71389E0824A7B13708AEFA66BA3698DAA255A4B85741B8ECC45C0CB1F3A3261C8230FB74253AB0BC326320DFBE699B347C5CD240BA4DE1EC1A07BA20442DC9430922CE95749B6D795CF8359691F5CC91A52169FF3B6403B4D97ED09D52540E3A83B7479770300A527CA040B43F5F24CFE17D8477D856FA6106575A9F41FD95AD4D717147A9A07A45D7AE45CB22A4F6482F2BB6A1B659B725EA74FE7C59AC24D5F0069D26956144BCC54FCE5D34C15FEFBD22CEEC6E0A85D1207EBD70B8B9397ACC49A4572F0F3B5D35D559CEC9BF6ED8A94E67AAAE54DCF1D9BAD720851BCE96F0263495F0A76B65F9D1A0F9EA6454B7624DE0EEE4B9B5B69"> </form>
• #64: This displays what is needed in creating a “tld” file. You define what the name of the tag is, what Java class is responsible for processing the tag, and whatever attributes are needed to support the tag.
• #65: This displays a Tag class. A typical tag class has a doStartTag() and a doEndTag() method. You decide which of these you need to override. Sometimes it will be both.
• #67: How does the controller Servlet learn about the mappings you want? Struts includes a Digester module that is capable of reading an XML-based description of the desired mappings, creating the appropriate objects along the way.
• #68: The two important elements are: <form-beans>This section contains your form bean definitions. You use a <form-bean> element for each form bean, which has the following important attributes: name: A unique identifier for this bean, which will be used to reference it in corresponding action mappings. Usually, this is also the name of the request or session attribute under which this form bean will be stored. type: The fully-qualified Java classname of your form bean. <action-mappings>This section contains your action definitions. You use an <action> element for each of your actions you would like to define. Each action element requires the following attributes to be defined: path: The application context-relative path to the action type: The fully qualified java classname of your Action class name: The name of your <form-bean> element to use with this action
• #69: Notice the <form-beans> tag section. Within this section you use the <form-bean tag to assign a name to your form bean, and in the type attribute you put the fully qualified class name. This class is always a descendent of ActionForm. Notice the <global-forwards> tag section. Within this section you use the <forward tag and assign a value to the name attribute. The name attribute is referenced by the Action class to determine if the action the user performed is this name, and if so it forwards to the value specified in the path attribute. In this example if the user clicked a button where the value of the button was “start”, the user would be sent to the index.html page. Notice the <action-mappings> tag section. Within this section you use the <action tag and assign several values. The first attribute is path, and is referenced by acion=“” within a JSP form. The next attribute (type), describes the name of the Action class. This class referenced here is always a decendent of org.apache.
• #70: The web.xml file is not something only used for Struts. It’s used in all J2EE web applications. It does have references to things that are Struts specific though.
• #71: Note that a web.xml file is not unique to Struts. When using WSAD and generating a web project, a web.xml file is automatically generated. However, it does not contain much that is useful. Typically a developer copies a web.xml file from an existing Struts based project, and then modifies it.
• #72: Note the line that has the <servlet-class> tag. It references the org.apache.struts.action.ActionServlet class. If you extend this class due to the necessity to provide additional functionality, you will need to reference your extended class here. Also not the <param-name> tag with the value of application. The following <param-value> tag is where you reference your projects property file.
• #73: Note the <welcome-file> tag. The value specified here is the start page of your application. This can either be an html file, or a Java Server Page. There are two common approaches to defining the URLs that will be processed by the controller Servlet -- prefix matching and extension matching. An appropriate mapping entry for each approach is described below. Prefix matching means that you want all URLs that start (after the context path part) with a particular value to be passed to this Servlet. Such an entry might look like this: <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>/execute/*</url-pattern> </servlet-mapping> which means that a request URI to match the /logon path described earlier might look like this: http://www.mycompany.com/myapplication/execute/logon where /myapplication is the context path under which your application is deployed. Extension mapping, on the other hand, matches request URIs to the action servlet based on the fact that the URI ends with a period followed by a defined set of characters. For example, the JSP processing servlet is mapped to the *.jsp pattern so that it is called to process every JSP page that is requested. To use the *.do extension (which implies "do something"), the mapping entry would look like this: <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> and a request URI to match the /logon path described earlier might look like this: http://www.mycompany.com/myapplication/logon.do
• #74: An entry defining the Struts tag library must be included in the web.xml file. If any custom tag libraries are used they must also be defined here.
• #75: Application Resource or property files are not unique to Struts applications. However, with the internationalization support built into Struts, they are used more.
• #76: Above is an example of an application resources property file. This file can contain any number of items. The one above shows examples of error messages, and text values used for things such as a title in your Java Server Page or the text on a button.
• #77: Many resources are available on the Internet. Currently there is only one published book on Struts, and it is not recommended by the author of these slides.
• #78: They’re many sites with Struts information. The third bullet item above displays a link to a page on the main Struts site which has links to many other sites. One other item worth mentioning is that IBM uses Struts. Some of the example projects included with WSAD use Struts.