Why are some of the class and element names counter-intuitive?
The framework grew in the telling and, as it evolved, some of the
names drifted.
The good thing about a nightly build, is that everything
becomes available to the community as soon as it is written. The bad thing
about a nightly build is that things like class names get locked down early and
then become difficult to change.
Why is ActionForm a base
class rather than an interface?
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
Do ActionForms have to
be true JavaBeans?
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.
Can I use multiple HTML form elements
with the same name?
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
Can I use multiple HTML form
elements with the same name?
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 <html:submit>
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.
Why doesn't the focus feature on the <html:form> tag work in every
circumstance?
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
<html:form> 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.
Why are my checkboxes not
being set from ON to OFF?
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.
Can't I just create some of my JavaBeans in the JSP using
a scriptlet?
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.
Can I use JavaScript to submit a form?
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.
No comments:
Post a Comment