Set - 3

Question 1 :

Why is ActionForm a base class rather than an interface?

Answer :

The MVC design pattern is very simple to understand but much more difficult to live with. You just need this little bit of Business Logic in the View logic or you need just that little bit of View logic in the Business tier and pretty soon you have a real mess.
Making ActionForm a class takes advantage of the single inheritance restriction of Java to it makes it more difficult for people to do things that they should not do.
ActionForms implemented as interfaces encourage making the property types match the underlying business tier instead of Strings, which violates one of the primary purposes for ActionForms in the first place (the ability to reproduce invalid input, which is a fundamental user expectation). ActionForms as an interface would also encourage using existing DAO objects as ActionForms by adding ‘implements ActionForm’ to the class. This violates the MVC design pattern goal of separation of the view and business logic.
Since the goal of struts is to enforce this separation, it just makes more sense for Struts to own the ActionForm.
DynaActionForms relieve developers of maintaining simple ActionForms. For near zero maintenance, try Niall Pemberton's LazyActionForm

Question 2 :

Do ActionForms have to be true JavaBeans?

Answer :

The utilities that Struts uses (Commons-BeanUtils since 1.1) require that ActionForm properties follow the JavaBean patterns for mutators and accessors (get*,set*,is*). Since Struts uses the Introspection API with the ActionForms, some containers may require that all the JavaBean patterns be followed, including declaring "implements Serializable" for each subclass. The safest thing is to review the JavaBean specification and follow all the prescribed patterns.
Since Struts 1.1, you can also use DynaActionForms and mapped-backed forms, which are not true JavaBeans. For more see ActionForm classes in the User Guide and Using Hashmaps with ActionForms in this FAQ.

Question 3 :

Can I use multiple HTML form elements with the same name?

Answer :

Yes. Define the element as an array and Struts will autopopulate it like any other.

private String[] id= {};
public String[] getId() { return; }
public void setItem(String id[]) { = id;}

And so forth

Question 4 :

Can I use multiple HTML form elements with the same name?

Answer :

Yes. The issue is that only one action class can be associated with a single form. So the real issue is how do I decode multiple submit types to a single Action class. There is more than one way to achieve this functionality.
The way that is suggested by struts is right out of the javadoc for LookupDispatchAction . Basically, LookupDispatchAction is using the keys from ApplicationProperties.resources as keys to a map of actions available to your Action class. It uses reflection to decode the request and invoke the proper action. It also takes advantage of the struts tags and is straight forward to implement.
You can roll your own with JavaScript events and javascript:void (document.forms["myform"].submit) on any html element. This gives you control of how you want your page to look. Again you will have to decode the expected action in the execute method of your action form if you choose this route.

Question 5 :

Why doesn't the focus feature on the tag work in every circumstance?

Answer :

Unfortunately, there is some disagreement between the various browsers, and different versions of the same browser, as to how the focus can be set. The tag provides a quick and easy JavaScript that will set the focus on a form for most versions of most browsers. If this feature doesn't work for you, then you should set the focus using your own JavaScript. The focus feature is a convenient "value-add" -- not a core requirement of the tag. If you do come up with a JavaScript that provides the final solution to this project, please post your patch to this Bugzilla ticket.

Question 6 :

Why are my checkboxes not being set from ON to OFF?

Answer :

A problem with a checkbox is that the browser will only include it in the request when it is checked. If it is not checked, the HTML specification suggests that it not be sent (i.e. omitted from the request). If the value of the checkbox is being persisted, either in a session bean or in the model, a checked box can never unchecked by a HTML form -- because the form can never send a signal to uncheck the box. The application must somehow ascertain that since the element was not sent that the corresponding value is unchecked.
The recommended approach for Struts applications is to use the reset method in the ActionForm to set all properties represented by checkboxes to null or false. The checked boxes submitted by the form will then set those properties to true. The omitted properties will remain false. Another solution is to use radio buttons instead, which always submit a value.
It is important to note that the HTML specification recommends this same behavior whenever a control is not "successful". Any blank element in a HTML form is not guaranteed to submitted. It is therefor very important to set the default values for an ActionForm correctly, and to implement the reset method when the ActionForm might kept in session scope.

Question 7 :

Can't I just create some of my JavaBeans in the JSP using a scriptlet?

Answer :

Struts is designed to encourage a Model 2/MVC architecture. But there is nothing that prevents you from using Model 1 techniques in your JavaServer Pages, so the answer to the question is "Yes, you can".
Though, using Model 1 techniques in a Struts application does go against the grain. The approach recommended by most Struts developers is to create and populate whatever objects the view may need in the Action, and then forward these through the request. Some objects may also be created and stored in the session or context, depending on how they are used.
Likewise, there is nothing to prevent you from using scriptlets along with JSP tags in your pages. Though, many Struts developers report writing very complex scriplet-free applications and recommend the JSP tag approach to others.
For help with Model 1 techniques and scriptlets, you might consider joining the Javasoft JSP-interest mailing list, where there are more people still using these approaches.

Question 8 :

Can I use JavaScript to submit a form?

Answer :

You can submit a form with a link as below. BTW, the examples below assume you are in an block and 'myForm' is picked up from the struts-config.xml name field of the action.

<a href='javascript:void(document.forms["myForm"].submit()>My Link</a> 

Now the trick in the action is to decode what action you intend to perform. Since you are using JavaScript, you could set a field value and look for it in the request or in the form. 
... html/javascript part ... 

<input type='hidden' value='myAction' />
<input type='button' value='Save Meeeee' onclick='document.forms["myForm"].myAction.value="save"; document.forms["myForm"].submit();' />
<input type='button' value='Delete Meeeee' onclick='document.forms["myForm"].myAction.value="delete"; document.forms["myForm"].submit();' />

... the java part ...

class MyAction extends ActionForm implements Serializable {
	public ActionForward execute (ActionMapping map, ActionForm form,
	HttpServletRequest req, HttpServletResponse) {
		String myAction = req.getParameter("myAction");
		if (myAction.equals("save") {
            // ... save action ...
        } else if (myAction.equals("delete") {
            // ... delete action ...

This is just one of many ways to achieve submitting a form and decoding the intended action. Once you get used to the framework you will find other ways that make more sense for your coding style and requirements. Just remember this example is completely non-functional without JavaScript.

Question 9 :

How do I use JavaScript to ... ?

Answer :

Struts is mainly a server-side technology. We bundled in some JSP tags to expose the framework components to your presentation page, but past that, the usual development process applies.
Interactive pages require the use of JavaScript. (That's why it was invented.) If you want things popping up or doing this when they click that, you are outside the scope of Struts and back into the web development mainstream.
You use JavaScript with Struts the same way you use with any presentation page. Since JavaScript is a client-side technology, you can use simple relative references to your scripts. If you need to fire a JavaScript from a HTML control, the Struts HTML tags have properties for the JavaScript events.
A very good JavaScript resource is Matt Kruse's site at Do I need to implement reset and set all my form properties to their initial values?
No. You need to set checkbox properties to false if the ActionForm is being retained in session scope. This is because an unchecked box does not submit an attribute. Only checked boxes submit attributes. If the form is in session scope, and the checkbox was checked, there is no way to turn it back off without the reset method. Resetting the properties for other controls, or for a request scope form, is pointless. If the form is in request scope, everything already just started at the initial value.

Question 10 :

Can I use other beans or hashmaps with ActionForms?

Answer :

Yes. There are several ways that you can use other beans or hashmaps with ActionForms.
* ActionForms can have other beansor hashmaps as properties
* "Value Beans" or "Data Transfer Objects" (DTOs) can be used independently of ActionForms to transfer data to the view
* ActionForms can use Maps to support "dynamic" properties (since Struts 1.1)
ActionForms (a.k.a. "form beans") are really just Java beans (with a few special methods) that Struts creates and puts into session or request scope for you. There is nothing preventing you from using other beans, or including them in your form beans. Here are some examples:
Collections as properties Suppose that you need to display a pulldown list of available colors on an input form in your application. You can include a string-valued colorSelected property in your ActionForm to represent the user's selection and a colorOptions property implemented as a Collection (of strings) to store the available color choices. Assuming that you have defined the getters and setters for the colorSelected and colorOptions properties in your orderEntryForm form bean, you can render the pulldown list using:

The list will be populated using the strings in the colorOptions collection of the orderEntryForm and the value that the user selects will go into the colorSelected property that gets posted to the subsequent Action. Note that we are assuming here that the colorOptions property of the orderEntryForm has already been set.
See How can I prepopulate a form? for instructions on how to set form bean properties before rendering edit forms that expect properties to be pre-set.
Independent DTO An Action that retrieves a list of open orders (as an ArrayList of Order objects) can use a DTO independently of any form bean to transfer search results to the view. First, the Action's execute method performs the search and puts the DTO into the request:
ArrayList results = businessObject.executeSearch(searchParameters);
Then the view can iterate through the results using the "searchResults" request key to reference the DTO:

..other properties...

Question 11 :

How can I scroll through list of pages like the search results in google?

Answer :

Many Struts developers use the Pager from the JSPTags site.

Question 12 :

Why do the Struts tags provide for so little formatting?

Answer :

The Struts tags seem to provide only the most rudimentary functionality. Why is there not better support for date formatting and advanced string handling?
Three reasons:
First, work started on the JSTL and we didn't want to duplicate the effort.
Second, work started on Java Server Faces, and we didn't want to duplicate that effort either.
Third, in a Model 2 application, most of the formatting can be handled in the ActionForms (or in the business tier), so all the tag has to do is spit out a string. This leads to better reuse since the same "how to format" code does not need to be repeated in every instance. You can "say it once" in a JavaBean and be done with it. Why don't the Struts taglibs offer more layout options?
Since the Struts tags are open source, you can extend them to provide whatever additional formatting you may need. If you are interested in a pre-written taglib that offers more layout options, see the struts-layout taglib.
In the same arena, there is a well regarded contributor taglib that can help you create Menus for your Struts applications.

Question 13 :

Why does the tag URL-encode javascript and mailto links?

Answer :

The tag is not intended for use with client-side references like those used to launch Javascripts or email clients. The purpose of link tag is to interject the context (or module) path into the URI so that your server-side links are not dependent on your context (or module) name. It also encodes the link, as needed, to maintain the client's session on the server. Neither feature applies to client-side links, so there is no reason to use the tag. Simply markup the client-side links using the standard tag.

Question 14 :

Why does the option tag render selected=selected instead of just selected?

Answer :

Attribute minimization (that is, specifying an attribute with no value) is a place where HTML violates standard XML syntax rules. This matters a lot for people writing to browsers that support XHTML, where doing so makes the page invalid. It's much better for Struts to use the expanded syntax, which works the same on existing browsers interpreting HTML, and newer browsers that expect XHTML-compliant syntax. Struts is following the behavior recommended by the XHTML specification

Question 15 :

Do I have to use JSPs with my application?

Answer :

The short answer to this question is: No, you are not limited to JavaServer Pages.
The longer answer is that you can use any type of presentation technology which can be returned by a web server or Java container. The list includes but is not limited to:
* JavaServer Pages,
* HTML pages,
* WML files,
* Java servlets,
* Velocity templates, and
Some people even mix and match apparently unrelated technologies, like PHP, into the same web application.

Question 16 :

Do ActionForms have to be true JavaBeans?

Answer :

ActionForms are added to a servlet scope (session or request) as beans. What this means is that, for certain functionality to be available, your ActionForms will have to follow a few simple rules.
First, your ActionForm bean must have a zero-arguments constructor. This is required because Struts must be able to dynamically create new instances of your form bean class, while knowing only the class name. This is not an onerous restriction, however, because Struts will also populate your form bean's properties (from the request parameters) for you.
Second, the fields of your form bean are made available to the framework by supplying public getter and setter methods that follow the naming design patterns described in the JavaBeans Specification. For most users, that means using the following idiom for each of your form bean's properties:

private {type} fieldName;
public {type} getFieldName() {
return (this.fieldName);

public void setFieldName({type} fieldName) {
this.fieldName = fieldName;

NOTE - you MUST obey the capitalization conventions shown above for your ActionForm properties to be recognized. The property name in this example is "fieldName", and that must also be the name of the input field that corresponds to this property. A bean property may have a "getter" method and a "setter" method (in a form bean, it is typical to have both) whose name starts with "get" or "set", followed by the property name with the first character capitalized. (For boolean properties, it is also legal to use "is" instead of "get" as the prefix for the getter method.)
Advanced JavaBeans users will know that you can tell the system you want to use different names for the getter and setter methods, by using a java.beans.BeanInfo class associated with your form bean. Normally, however, it is much more convenient to follow the standard conventions.
WARNING - developers might be tempted to use one of the following techniques, but any of them will cause your property not to be recognized by the JavaBeans introspection facilities, and therefore cause your applications to misbehave:
* Using getter and setter method names that do not match - if you have a getFoo() method for your getter, but a setBar() method for your setter, Java will not recognize these methods as referring to the same property. Instead, the language will think you have a read-only property named "foo" and a write-only property named "bar".
* Using more than one setter method with the same name - The Java language lets you "overload" methods, as long as the argument types are different. For example, you could have a setStartDate(java.util.Date date) method and a setStartDate(String date) method in the same class, and the compiled code would know which method to call based on the parameter type being passed. However, doing this for form bean properties will prevent Java from recognizing that you have a "startDate" property at all.
There are other rules to follow if you want other features of your form beans to be exposed. These include indexed attributes and mapped attributes. They are covered in detail in other areas of the Struts documentation, in particular: indexedprops.html

Question 17 :

Do I have to have a separate ActionForm bean for every HTML form?

Answer :

This is an interesting question. As a newbie, it is a good practice to create a new ActionForm for each action sequence. You can use DynaActionForms to help reduce the effort required, or use the code generation facilities of your IDE.
Some issues to keep in mind regarding reuse of form beans are as follows:
* Validation - You might need to use different validation rules depending upon the action that is currently being executed.
* Persistence - Be careful that a form populated in one action is not unexpectedly reused in a different action. Multiple entries in struts-config.xml for the same ActionForm subclass can help (especially if you store your form beans in session scope). Alternatively, storing form beans in request scope can avoid unexpected interactions (as well as reduce the memory footprint of your application, because no server-side objects will need to be saved in between requests.
* Checkboxes - If you do as recommended and reset your boolean properties (for fields presented as checkboxes), and the page you are currently displaying does not have a checkbox for every boolean property on the form bean, the undisplayed boolean properties will always appear to have a false value.
* Workflow - The most common need for form bean reuse is workflow. Out of the box, Struts has limited support for workflow, but a common pattern is to use a single form bean with all of the properties for all of the pages of a workflow. You will need a good understanding of the environment (ActionForms, Actions, etc.) prior to being able to put together a smooth workflow environment using a single form bean.
As you get more comfortable, there are a few shortcuts you can take in order to reuse your ActionForm beans. Most of these shortcuts depend on how you have chosen to implement your Action / ActionForm combinations.

Question 18 :

How can I prepopulate a form?

Answer :

The simplest way to prepopulate a form is to have an Action whose sole purpose is to populate an ActionForm and forward to the servlet or JSP to render that form back to the client. A separate Action would then be use to process the submitted form fields, by declaring an instance of the same form bean name. 
The struts-example example application that is shipped with Struts illustrates this design pattern nicely. Note the following definitions from the struts-config.xml file: 

<-- Registration form bean -->
<form-bean name="registrationForm" type="org.apache.struts.webapp.example.RegistrationForm"/>
<-- Edit user registration -->
<action path="/editRegistration" type="org.apache.struts.webapp.example.EditRegistrationAction" name="registrationForm" scope="request" validate="false"/>
<-- Save user registration -->
<action path="/saveRegistration" type="org.apache.struts.webapp.example.SaveRegistrationAction" name="registrationForm" input="registration" scope="request"/>

Note the following features of this approach:
* Both the /editRegistration and /saveRegistration actions use the same form bean.
* When the /editRegistration action is entered, Struts will have pre-created an empty form bean instance, and passed it to the execute() method. The setup action is free to preconfigure the values that will be displayed when the form is rendered, simply by setting the corresponding form bean properties.
* When the setup action completes configuring the properties of the form bean, it should return an ActionForm that points at the page which will display this form. If you are using the Struts JSP tag library, the action attribute on your <html:form> tag will be set to /saveRegistration in order for the form to be submitted to the processing action.
* Note that the setup action (/editRegistration) turns off validation on the form that is being set up. You will normally want to include this attribute in the configuration of your setup actions, because you are not planning to actually process the results -- you simply want to take advantage of the fact that Struts will precreate a form bean instance of the correct class for you.
* The processing action (/saveRegistration), on the other hand, leaves out the validate attribute, which defaults to true. This tells Struts to perform the validations associated with this form bean before invoking the processing action at all. If any validation errors have occurred, Struts will forward back to your input page (technically, it forwards back to an ActionForward named "registration" in this case, because the example webapp uses the inputForward attribute in the element -- see the documentation describing struts-config.xml for more information) instead of calling your processing action.

Question 19 :

Can I have an Action without a form?

Answer :

Yes. If your Action does not need any data and it does not need to make any data available to the view or controller component that it forwards to, it doesn't need a form. A good example of an Action with no ActionForm is the LogoffAction in the struts example application:

<action path="/logoff" type="org.apache.struts.webapp.example.LogoffAction">
	<forward name="success" path="/index.jsp"/>

This action needs no data other than the user's session, which it can get from the Request, and it doesn't need to prepare any view elements for display, so it does not need a form.

However, you cannot use the <html:form> tag without an ActionForm. Even if you want to use the <html:form> tag with a simple Action that does not require input, the tag will expect you to use some type of ActionForm, even if it is an empty subclass without any properties.

Question 20 :

Can you give me a simple example of using the requiredif Validator rule?

Answer :

First off, there's an even newer Validator rule called validwhen, which is almost certainly what you want to use, since it is much easier and more powerful. It will be available in the first release after 1.1 ships. The example shown below could be coded with validwhen as:

<form name="medicalStatusForm">
<field property="pregnancyTest" depends="validwhen">
<arg0 key="medicalStatusForm.pregnancyTest.label"/>
<var-value>((((sex == 'm') OR (sex == 'M')) AND (*this* == null)) OR (*this* != null))</test></var>

Let's assume you have a medical information form with three fields, sex, pregnancyTest, and testResult. If sex is 'f' or 'F', pregnancyTest is required. If pregnancyTest is not blank, testResult is required. The entry in your validation.xml file would look like this:

<form name="medicalStatusForm">
<field property="pregnancyTest" depends="requiredif">
<arg0 key="medicalStatusForm.pregnancyTest.label"/>

property="testResult" depends="requiredif">
<arg0 key="medicalStatusForm.testResult.label"/>