Checkboxes in Stripes and Spring MVC

When building dynamic web sites with lots of javascript UI components being created on the client, understanding how the web framework you’re using will process the request and what must be done to update fields accordingly is even more important.

Specifically, checkboxes have always been a pain to deal with. The gotcha with checkboxes are if a checkbox isn’t checked, the request doesn’t send the parameter so it requires some additional checks to detect that the user deselected something that was there to update the field accordingly. I’ve been playing around with the Stripes framework and ran into this issue.

With Stripes, you can render a checkbox using their JSP tag:

<stripes:checkbox checked="true" name="property1" value="yes"/>
<stripes:checkbox checked="true" name="property2" value="no"/>

When the “checked” value is equal to “value” value, Stripes will render the checkbox as checked. So with the code shown, two checkboxes will be shown with the first checked and the second unchecked.

If a user reverses this by unchecking the first, checking the second, and submit the form, the HTTP request will only see that property2=no. Before the form was submitted, “property1″ had a value of “yes”. Now, “property1″ won’t even appear in the request parameters, so we have to do special handling to check for the absent of the parameter to update “property1″ to whatever value it should be when it is not checked.

In Spring MVC with form binding, checkboxes are dealt with a little differently. Using Spring MVC’s form JSP tag, you can do:

  <form:checkbox path="property1" value="yes"/>
  <form:checkbox path="property2" value="no"/>

Assuming your command bean is named “person”, this will generate the following HTML:

        <input name="person.property1" type="checkbox" value="yes"/>
        <input type="hidden" value="1" name="_person.property1"/>
        <input name="person.property2" type="checkbox" value="no"/>
        <input type="hidden" value="1" name="_person.property2"/>

As noted by the docs,

What you might not expect to see is the additional hidden field after each checkbox. When a checkbox in an HTML page is not checked, its value will not be sent to the server as part of the HTTP request parameters once the form is submitted, so we need a workaround for this quirk in HTML in order for Spring form data binding to work. The checkbox tag follows the existing Spring convention of including a hidden parameter prefixed by an underscore (“_”) for each checkbox. By doing this, you are effectively telling Spring that “the checkbox was visible in the form and I want my object to which the form data will be bound to reflect the state of the checkbox no matter what”.

Spring MVC also provides a “checkboxes” tag which allows you to render a list of checkbox boxes without having to wrap the “checkbox” tag around a JSTL forEach.

Hopefully, that gives you some insight into how to work with checkboxes in Stripes and Spring MVC.

Run Firefox 2 and Firefox 3

Gah, why would you want to run both? Well, Firebug is the suck in Firefox 3. I’ve been doing a lot of javascript/ajax development lately.

When using Firefox 3 and the Firebug console, I get the following error occasionally:

commandLine.evaluate FAILS: [Exception... "Security Manager vetoed action" nsresult: "0x80570027 (NS_ERROR_XPC_SECURITY_MANAGER_VETO)" location: "JS frame :: chrome://firebug/content/commandLine.js ::  :: line 100" data: no]

Lifehacker had a nice post on how to run Firefox 2 and 3.

For most cases Firefox 3 is just fine. But for the serious javascript coder, Firebug just isn’t ready for prime time in Firefox 3.

KML – the new mapping standard

The Open Geospatial Consortium just announced that KML has been adopted as an open standard. KML stands for Keyhole Markup Language, originally designed by Keyhole who was acquired by Google back in 2004. Keyhole’s Earth Viewer product was reborn as what we know today as Google Earth. I first came across KML when I was working on some data visualization using Google Earth. I found it to be very expressive and easy to use. You can do neat things like stream dynamic KML to animate the map or add overlays on the map.

It’s interesting to see how Google Earth/Maps’s popularity has allowed KML to become the international standard. It will be even more interesting to see how quickly the standard is adopted by many of the geo-visualization products out there. While I don’t think it will be “the HTML of geographic content“, I do think this standardization will open up the market for new products that build/support KML, pushing KML to its limits as we have done with HTML.