Struts Tip #7 – Use Multibox to manage checkboxes

Many applications need to use a large number of checkboxes to track options or selected items. To help with this, Struts provides the multibox control. It’s quite handy but a little tricky to understand at first.

The multibox leverages the way HTML handles checkboxes. If the box is not checked, the browser does not submit a value for the control. If the box is checked, then the name of the control and its value are submitted. This behavior is the reason there is a reset() method on the ActionForm. Since the browser will never signal that a box has been un-checked, the only solution is to reset all the boxes, and then check the ones that are now present in the request.

The multibox control is designed to use an array of Strings. Each element in the array represents a checked box. To check a box, add a String to the array with the box’s value. To uncheck a box, remove the element from the array. (Sound familiar?)

When passed a value, the multibox control scans the elements of its array to see if there is a match. If so, the box is checked. If not, the box is left unchecked. If the user checks the box and submits the form, the box’s value will be included in the request. The controller will then add that box to the “checked” array. If a box is unchecked, nothing is submitted, and nothing is added to the array. If the ActionForm bean is kept in the session context, in between requests, the reset() method needs to reduce the array to zero length (but not null).

In this example,

<logic:iterate id="item" property="items">
<html:multibox property="selectedItems">
<bean:write name="item"/>
</html:multibox>
<bean:write name="item"/>
</logic:iterate>

The labels for the individual checkboxes is in the items property. The list of selected items is in an array named selectedItems. Items that are not selected are not present in the selectedItems array. The multibox checks the selectedItems array for the current item. If it is present, it writes a checked checkbox. If not, it writes an unchecked checkbox.

Given an ActionForm setup like this

private String[] selectedItems = {};
private String[] items = {"UPS","FedEx","Airborne"};
public String[] getSelectedItems() {
return this.selectedItems;
}
public void setSelectedItems(String[] selectedItems) {
this.selectedItems = selectedItems;
}

The markup in the example would generate three checkboxes, labeled UPS, FedEx, and Airborne.

<input type="checkbox" name="selectedItems" value="UPS">UPS
<input type="checkbox" name="selectedItems" value="FedEx">FedEx
<input type="checkbox" name="selectedItems" value="AirBorne">AirBorne

Initially, the selectedItems array would be empty. If UPS were checked and submitted, it would become the equivalent of

private String[] selectedItems = {"UPS"};

If UPS and Airborne were both checked, it would become the equivalent of

private String[] selectedItems = {"UPS","Airborne"};

And when the checkboxes are rendered, the appropriate elements are automagically checked by the multibox tag.

<input type="checkbox" name="selectedItems" value="UPS" checked="checked">UPS
<input type="checkbox" name="selectedItems" value="FedEx">FedEx
<input type="checkbox" name="selectedItems" value="AirBorne" checked="checked">AirBorne

To provide different sets of labels and values, the standard LabelValueBean class [org.apache.struts.util.LabelValueBean] (since 1.1) can be used with the multibox control.

<logic:iterate id="item" property="items">
<html:multibox property="selectedItems">
<bean:write name="item" property="value"/>
</html:multibox>
<bean:write name="item" property="label"/>
</logic:iterate>

HTH, Ted.

http://www.jguru.com/faq/view.jsp?EID=925277

Difference between Request MVC and Component MVC

In request (action) based MVC, a single front controller servlet will delegate to action models based on request URL/params. You works directly with raw HttpServletRequest and HttpServletResponse objects in the action model. You’ve to write code yourself to gather, convert and validate the request parameters and if necessary update the model values before you can ever invoke the business action.
In component based MVC, a single front controller will gather, convert and validate request parameters and update the model values itself so that you only need to worry about the business action yourself. How the controller needs to gather/convert/validate/update the values is definied in a single place, the view. Since that’s not possible with “plain” HTML, a specific markup language is required to achieve the goal. In case of JSF 2.0, that’s XML (XHTML) based. You use XML to define UI components which in turn contain information about how the controller should gather/convert/validate/update the values and itself generate the necessary HTML representation.
Advantages and disadvantages should be clear at this point: With a request based MVC framework you need to write more code yourself to achieve the goal. However you end up with much more fine grained control over the process and the HTML/CSS/JS output. With a component based MVC framework you don’t need to write much code yourself. However you have less fine grained control over the process and the HTML/CSS/JS output. So if you’d like to do things a bit differently than the standard describes, you’ll waste a lot more time in a component based MVC framework.

See also:

Accessing a value in Struts ActionForm from JSP

Try
<h1>Hello  <bean:write name="RegistrationForm" property="userid" />!</h1>
it doesn’t matter what the internal name / coding of your formbean is. All what matters is how the getters and setters are named. Your getter is named getUserid() to the javabean property is userid.

how to use tag in strut 1.2?

Javadoc for :
Specifies the attribute name of the bean whose property is accessed to retrieve the value specified byproperty (if specified). If property is not specified, the value of this bean itself will be rendered.
In essence, if you have a JavaBean (with getters and setters),
Person person = new Person;
request
.setAttribute("person", person);
by setting , you’re telling Struts to first findperson object first from PageContext scope. If not found, then request, then session, thenapplication scope.
The property="age" attribute (from  tag), will then call the getter methodgetAge() from the Person object (irrespective of whether there’s an instance variable called ageon the bean).
Hope this helps.

Actual Use Of validate and input in struts config file

These attributes are only used if you’re using the Struts Validator Framework or if you override the validate(…) method of your ActionForm. The validate attribute indicates whether or not validation will be performed for this action, and the input attribute indicates where to forward if there is a validation error.

For more information on how to use the validator framework, see the Struts Validator Guide.
[ July 25, 2008: Message edited by: Merrill Higginson ]

http://www.coderanch.com/t/59130/Struts/Actual-validate-input-struts-config

"parameter" attribute in the action-mapping… what is it?

It’s a general purpose attribute you can use to pass any desired
information into the action from the struts-config.xml file.  You can
access the parameter’s value within the action class via the
mapping.getParameter() method.  For actions requiring multiple steps, the
parameter is often used to indicate which step the mapping is associated
with.  For example:

               type=”myactions.CreateSomethingAction”
               …
               parameter=”step1″>…

               type=”myactions.CreateSomethingAction”
               …
               parameter=”step2″>…

               type=”myactions.CreateSomethingAction”
               …
               parameter=”complete”>…

I hope this helps.  Take care.

Don

http://www.mail-archive.com/struts-user@jakarta.apache.org/msg25267.html

Testing DispatchAction with StrutsTestCase

Al,

I just set the appropriate request parameter. If the parameter is 'method'
and the method I want to test is 'get', it would look like this:

addRequestParameter("method", "get");

On 2004-Feb-02 10:02, Al Rathon wrote:
> Hi:
> I am working working on a Struts based web-app that
> uses DispatchAction to club the methods belonging to
> each entity in one Action class. I would like to know
> how to test such an action class using struts test
> case.
>
> Thanks in advance for the help.
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe jakarta.apache.org
> For additional commands, e-mail: struts-user-help jakarta.apache.org
 
http://permalink.gmane.org/gmane.comp.jakarta.struts.user/75447 

Difference between ValidatorForm and DynaValidatorForm

The answer to this is in fact the difference between ActionForm and DynaActionForm.
In Struts, everybody knows the ActionForm class (so I’m not gonna talk about it). But not everybody knows (or understands the purpose of – me included) the DynaActionForm.
The idea behind DynaActionForms is that instead of creating a form class for each HTML form, you instead configure one (you declare their properties, types and defaults in the struts-config.xml file). It was supposed to be “Dyna”mic you know… but turned out to be some thing that nobody understood or used and presented some major disadvantages:
  • they act sort of like a Map so it has the same problems of maps, like retrieving data from it, you know, as an Object which you then have to cast. So you have casts everywhere;
  • compiler no longer notifies you when you screw something up like a name of a property for example, so compile errors turn into runtime errors;
  • the things are not really dynamic since you still have to restart the server after you “reconfigured” the properties in the struts-config.xml file (or else modifications won’t be picked up);
  • code completion does not work on DynaActionForms, type safety sucks (we are not taking generics here) and there are other nuisances that I can’t remember right now.
Well… the idea is that, from a Struts point of view, you have two main types of forms to deal with: ActionForm and DynaActionForm (even if the DynaActionForm is in fact a subclass of ActionForm).
But you also have the validator plugin where you place your validation rules in an external file and make them pick up by your action forms. You hook up the validator plugin by using a child of ActionForm: the ValidatorForm. And since you have two types of forms you must hook up the validator plugin for the DynaActionForms also: enter the DynaValidatorForm.
In conclusion, the ValidatorForm and DynaValidatorForm are the same thing but applied to different “beasts”.