Danilo Gurovich

+ Follow
since Aug 08, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Danilo Gurovich

I really appreciate the thoughtful questions, and I hope that our book will help your readers. I'm a big fan of JavaRanch, and will check back in often.
15 years ago
It really depends on how "production level" your code is going to be, and what you'll be doing with it from there. I would suggest a tiles based solution that loads an independent template and then you can load tiles in and out of the page depending upon your view.

Think of Tiles as a "controller" for your view layer, with the individual tiles and templates controlled by your definitions. Your Actions then call definitions only, and you can then fully encapulate your application and really lower the amount of duplicated code, so anytime you change something once, it changes it everywhere.

There's always a trade off. Sometimes it's the speed of development, sometimes it's in maintenance, sometimes it's just philosophy. I don't like to have logic on my page that says "well, show this, unless something here is happening, or something here, or....". You end up getting into some maintenance issues....
15 years ago
There is no "automatic" way to do this, but I do have a "lost recipe" that didn't make it into the book that I'll post below (please excuse any typos)......

A Simple Radio Button Solution

How can I create a JSP page with dynamic radio buttons?

Struts allows for the creation of dynamic radio buttons by nesting the �<logic:iterate/>� and �<html:radio/>� tags referring to an instantiated bean (our example uses the form bean). This nesting works by iterating through a list of radio button values and assigning an identical �name� attribute and the proper value attribute. By using another variable field we can also compare the two lists and assign a predetermined �checked� attribute, if necessary. The big difference between the radio button implementation and the �multibox� implementation in another recipe is how the pre-selected button is created. While it is a fairly simple matter to pre-select checkboxes, the radio button needs a different solution that is readily accomplished using the form bean and a couple of lines of JavaScript!

The Java class formBean does a lot of the heavy lifting in this simple case. The values that you may ultimately wish to populate your application may come from databases, separate beans, DynaActions, EJB�s or combinations of all of these. For purposes of simplicity and clarity, we�ll start with the simple example below:


package com.strutscookbook;

import ...;

* Creates a String[] mountains for Radio buttons,
* and a String selectedMountains for the pre-selected
* radio button
* @author Danilo Gurovich
public final class RadioTestForm
extends ActionForm {

// Instance Variables

/*Mountains "pre-selected"...*/
private String selectedMountains = "Kangchenjunga";

/*Mountains for radio buttons*/
private String[] mountains = {"Everest","K2","Kangchenjunga","Lhotse",
"Makalu" ,"Cho Oyu"};

/*Getter for selectedMountains*/
public String getSelectedMountains() {
return this.selectedMountains;
/*Setter for selectedMountains*/
public void setSelectedMountains(String selectedMountains) {
this.selectedMountains = selectedMountains;

/*Getter for the mountains*/
public String[] getMountains() {
return this.mountains;
/*Setter for the mountains*/
public void setMountains(String[] mountains) {
this.mountains = mountains;

All of the java code for this Form Bean (except the usual imports) is included to make sure that there are no discrepancies as to what is needed. Notice that �Kangchenjunga� is listed in both the �selectedMountains� and �mountains� field. We will propagate �Kangchenjunga� to the JSP as the �pre-selected� initial value.

Here is the pertinent JSP Code for the corresponding page. As always, make sure that you import the corresponding struts tags onto your page. Note the correlation between the java files and the �logic�, �html� and �bean� tags, and the JavaScript function located at the bottom of the form:


<%@ taglib uri="/tags/struts-bean" prefix="bean" %>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>


<html:form action="/FormAction"

<h4><bean:message key="testForm.instruction"/></h4>

<!-- gets the "selected" radio button -->
<bean efine id="selectedRadio" property="selectedMountains" name="testForm"/>

<!-- creates the radio button list -->
<logic:iterate id="mountain" property="mountains" name="testForm">
<bean efine id="mountainValue"><bean:write name="mountain"/></bean efine>
<html:radio property="selectedMountains" value="<%=mountainValue%>" styleId="<%=mountainValue%>"/>
<bean:write name="mountain"/><br/>

<script language="JavaScript">
var selRadio = document.getElementById("<bean:write name="selectedRadio"/>");

JavaScript is going to do the work here. First, we define a JSP scripting variable for our �selectedMountain� field above inside the form:

<bean efine id="selectedRadio" property="selectedMountains" name="testForm"/>

then, we create a JavaScript function below the form. This function consists of two lines:

var selRadio = document.getElementById("<bean:write name="selectedRadio"/>");

Here�s what�s happening. We create a �selRadio� JavaScript variable, then find all of the elements in the document that have an �id� (or �styleId� in the pre-compiled code) matching the �selectedRadio� variable. We�ve accomplished this by setting the �<html:radio/>� tag�s �styleId� attribute to match it�s name/value. While the JavaScript function quickly iterates through the id�s on the page, it simply sets our singular radio button as selected.

Another JavaScript method is available to produce the same results, only with a method:

var selectedRadio =

This particular script discriminates to only the form elements �name� instead of �id�. Either System will work perfectly, the dependency exists on extending or scaling of other objects on your page. The output from our JSP looks like:

Cho Oyu
15 years ago
Sorry for the double posting, I hit the reply button too fast. Here's my answer.

Here's a little snippet of code showing <logic:iterate/> tags used to create checkboxes (using a String[] here:

<logic:iterate id="theInstanceOfIteration"
<html:multibox property="selectedMountains">
<bean:write name="theInstanceOfIteration"/>
<bean:write name="theInstanceOfIteration"/><br/>
15 years ago
I would eschew using a map for this, because sometime in the future you may want to have checkboxes mapped to the same value, and it will be very frustrating to manage this. I feel that a better choice would be to create a List of LabelValueBeans, and then iterate through these. If you create the list as some kind of a lookup object then you'll be able to just "grab" the list you need whenever you need it.
15 years ago
You can also implement this functionality using struts-layout tags from the struts-layout home
15 years ago
I would recommend "Struts in Action". If you read the first few chapters in it and "get" what is happening, you should be able to begin developing quickly.

Make sure that you understand what MVC2 "architecture" is.

Struts will "help" you implement good MVC2 practices, but it won't prevent you from creating Struts Applications that are incorrectly written. To get around this type of pitfall, here are a few of my recommendations...

WRT the JSP side of your code, you'll need to understand JSP tags and taglibs. You'll also need to make sure that your business logic isn't in your View Layer (JSPs), but safely encapsulated in your server-side. Your JSP's should only have information and code in it that is specifically related to your view.

When you create Actions, make sure that there is little or no business logic in them. Basically, they should be used to pass information from the View to your Model for processing and back, with the only logic in these classes based upon where to direct the response. If you encapsulate your business logic in this layer, you risk duplication of code at least, and if you should decide to abandon Struts for something else, you could end up rewriting thousands of lines of code to more all that business logic.

As far as your back end goes, it should be completely encapsulated and "not care" about the view. You should think along the lines of your business layer operating from a command line, Swing Client, JSPs, or any other view layer. If it is dependent upon a View technology, then you probably need to do more work.

Once you are at this point, you can begin your migration. I'm going to discuss this using the struts tag library in its 1.1 form (Since I don't know what servlet container you're running or what Java/JSP you are using, this is a safe bet. If you want to upgrade to Struts 1.2x you're more than welcome to as long as you're familiar enough with what's going on). I would recommend implementing:

All your links should be changed to actions registered in the Struts-config.xml file.

Wherever any URL references or sources are in your code, you should use the <html:rewrite/> tag or an appropriate tag that will utilize url rewriting and encoding.

Create Form beans and join them to your actions.

Create validations

Tile and template your application -- you may want to use JSP tiles at first and then move to the tiles-definitions.xml file at a future date, depending upon the size and complexity of the application you are migrating.

Finally, add Struts' validations.

By the time you reach this point, your migration will be 80-90% complete and you'll have a pretty good idea as to how to proceed from this point.
15 years ago