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 this.id; }
public void setItem(String id[]) {this.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.