Use a Spring InitBinder to Resolve Type Mismatch and Bind Exceptions in POST from Spring Framework MVC Forms to Controller Actions

As a follow up to the previous article on binding entities and their children to form objects in Spring Framework it’s important to know how to submit the values of form objects in a standard form back to the controller. In the previous example we had a “Parent” entity, with a dropdown “select” on the form where you could choose one of the available “Children” objects. We also had a “Description” textbox that allowed the user to type in a suitable description.

The actual form, a very simple interface with both these elements and a submit button looks like:

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://www.springframework.org/tags/form" prefix="form" %>

<c:url var="saveParentUrl" value="/parent/save" />
<form:form modelAttribute="parent" method="POST" action="${saveParentUrl}">
Description:  <form:input path="description"/>
Child:  <form:select path="child" id="child" items="${children}" itemValue="id" itemLabel="name"/>
<input type="submit" value="Save Parent" />
</form:form>

In this example, when the user clicks on the “Save Parent” button the form will be posted to the “parent” controller action “saveParent” at “/parent/save” where we can save the updated “Parent” object.

Now the problem is that the POST header only contains text strings, not a full description of the actual “Child” object we have chosen for “Parent”. When you try to save the “Parent” object in the controller action the result is an exception,  “org.springframework.validation.BeanPropertyBindingResult”. The error message itself tells you exactly what is happening:

default message [Failed to convert property value of type ‘java.lang.String[]’ to required type ‘models.Child’ for property ‘Child’; nested exception is java.lang.IllegalStateException: Cannot convert value of type ] to required type [models.Child] for property ‘Child’: no matching editors or conversion strategy found]

The message tells you that Spring can’t automatically convert from the POST string value of the “child” select option (actually “id” in our case) to an actual “Child” object. We need to convert this string to a “Child” object in order to save the updated “Parent” entity. This is easily achieved using an “InitBinder” method within the controller class and a “@Validated” annotation on the “save” action’s “Parent” “@ModelAttribute” argument.

The code for the controller action looks like the following. Note that in this example I am using a “parentService” to pull the protocol to be updated from a “Parent” stored in session. It is likely that you will have something different or even pass in the id as part of the POST:

// ParentController.java
@RequestMapping(value = "/save", method=RequestMethod.GET)
public ModelAndView saveParent (@Validated @ModelAttribute("parent") Parent formparent, HttpServletRequest request )
{
    ...
    // find parent to update in database using parent service
    Parent parent = parentService.findById(sessionparent.getId());

    // set parent description and Child based on user input and save
    parent.setDescription(formparent.getDescription());
    parent.setChild(formparent.getChild());
    parentService.saveParent(parent);
    ...
}

The “formparent” is the “Parent” object passed in POST and mapped by Spring using the “@ModelAttribute” annotation. The “InitBinder” required to map the “Child” id passed in as part of POST to an actual “Child” object is:

@InitBinder
protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) throws Exception {
    binder.registerCustomEditor(Child.class, "child", new PropertyEditorSupport() {
    @Override
    public void setAsText(String text) {
        Child ch = childService.findById(Long.parseLong(text));
        setValue(ch);
    }
    });
}

What this does is register a binder for the “child” object when it is passed from the form to Spring that converts the value to an actual object. By overriding the “SetAsText” function I use a “childService” service to retrieve the correct “Child” entity based on the text value passed in POST. Spring can now understand and convert the POST values to actual objects and the “Parent” entity can be safely modified by the “saveParent” controller action mapped to “/parent/save”. More information and some alternative methods are available at Develop and Conquer and Empire5.

Binding Entities and Their Children to Java JSP Form Elements in Spring Framework MVC

Binding objects to JSP form elements is actually quite easy in Spring Framework using the “modelAttribute” and “path” tags. Our scenario was the use of two Hibernate POJOs comprised of a parent entity “Parent” and a single “Child” entity which needed to be displayed on screen with appropriate form elements (“input” and “select”). The entities were annotated for use as part of a larger application but the basic structure was:

// Parent.java
public class Parent{
  private Int id
  private String description
  private Child child
  ...
}

// Child.java
public class Child{
  private Int id
  private String name
  ...
}

To display these objects on screen as part of a form in Spring Framework MVC we used the following “ParentController” controller with a “showparent” action. The action uses a “parentService.getParent(id)” method (not shown) to retrieve a single parent entity based on “id” and attach it to the form using a Map “model” and a returned “ModelAndView”. A “childService” is used to get the list of every possible child entity (also not shown) and this is also added to the “ModelAndView”:

// ParentController.java
@RequestMapping(value = "/showparent", method=RequestMethod.GET)
public ModelAndView protocolList(HttpServletRequest request)
{
	...
	Map<String, Object> model = new HashMap<String, Object>();
	model.put ( "children", childService.getAll());
	model.put ( "parent", parentService.getParent(id));
	return new ModelAndView ( "showparent", model );
}

The form itself is very simple and uses Spring binding to automatically create and populate input fields:

<%@ taglib uri="http://www.springframework.org/tags/form" prefix="form" %>
<form:form modelAttribute="parent" >
Description:  <form:input path="description"/>
Child:  <form:select path="child" id="child" items="${children}" itemValue="id" itemLabel="name"/>
</form:form>

Spring Framework uses the “modelAttribute” and “path” tags to determine what is set on the form. In this case the forms “modelAttribute” is “parent” which means that the elements in the form are properties of the “parent” entity. The “description” is shown as the contents of a simple textbox input using “form:input”. The interesting part is the “form:select” which automatically populates the select with option objects based on the set of “child” objects in “children” and selects the correct “child” option for the “parent” based on the “itemValue”, “id” in this case.

Submitting changes to “parent” entities is covered in my more recent post.

Combine JQuery, JSON and Zend Framework MVC actions to update page items dynamically using AJAX

In order to populate and dynamically update a table on one of our Zend framework based pages without refreshing the page we had to use a combination of JQuery, JSON and standard Zend views/forms. The JQuery is part of the view and is inserted in <script> blocks while a standard Zend form is used to populate the page with dropdown menus, text boxes etc. JSON is used to handle passing data between the client side JQuery and the server side Zend action.

The following is a simple example, which passes JSON stored by JQuery in a hidden field to a Zend action on the server to update a database. Where possible the code has been simplified (so no long winded database connection etc  etc). As getting Zend framework up and running can be a bit difficult from scratch, this is not covered here. The Zend Framework Quickstart is useful although personally I think it could be clearer for first time users. Although I use modules in Zend to split different sections of my web application into self contained areas, for this example I will keep it as simple as possible and not use modules. To keep things even more simple I am not going to describe any validation or POST handling of the Zend action, we are only concerned with JQuery/Zend integration.

The example action we are going to call is the LIST action in the VISIT controller, which will show a list of visits and allow us to add a new one using a simple one textbox interface. JQuery will be used to pull all the required table data from the server and handle the visual client side aspect of adding a new visit.

The controller VisitController.php will have a very simple LIST action that looks like the following:

public function listAction()
{
  // set the view title to "Visit List"
  $this->view->title = "Visit List";
  // create a new Form_ListVisit() form object and add it to the view
  $newVisitForm = new Form_ListVisit();
  $this->view->form = $listVisitForm;
}

All this action does is set the view title, generate a Form object from a Zend form Form_ListVisit() and set the view form to this object (thereby placing the form on the page). The action will not do anything without a corresponding view script and Zend form, which both need to be created as separate files in the correct location in your file structure (more than likely /views/scripts/visit/list.phtml and /forms/ListVisit.php). Again, use of views and Zend forms is standard Zend Framework practice and is beyond the scope of this simple example.

For the view, currently without any JQuery, it will also be very simple:

<?php
  echo "<h1>".$this->title."</h1>";
  echo $this->form;
  echo "<div class='statusmessage'></div>";
?>

All this does is place the title and the form on the page that is displayed to the user, both the title and the form are set in the controller (see above). In a moment the JQuery will be placed in a <script> tag above this <?php ?> section, although it is a good idea to refactor your code to keep the view as simple as possible by having the JQuery code in a separate .js file. The “statusmessage” div will be used by JQuery to place success/error message on screen when we update the database.

The ListVisit.php Zend form file is more complicated and in the real world can take a while to write, including all the objects, decorators, subforms, validation options etc. In this case we keep it very simple and just add a single hidden field that we will use to store a single JSON string and a textbox to handle user input:

class Form_ListVisit extends ZendX_JQuery_Form
{
  public function init()
  { 
    // add the hidden field used to store our JSON string 
    $hiddenjson = $this->createElement('hidden','hiddenjson');
    $this->addElement($hiddenjson);
    // add the textbox used to handle user input
    $inputfield = $this->createElement('text', 'inputfield', array('Label' => 'Enter new data here'));
    $this->addElement($inputfield);
  }
}

So on loading the NEW action on the VISIT controller we end up with a blank page with only a title that says “Visit List” and a single textbox. The hidden field placed on the page by the Zend form is there but is empty, there is no table on screen and no other links. In this example we are going to add everything else we need, such as the table of visits, link to add new visit and link to save to the database, using JQuery. The communication between the client side and the server is handled using JQuery’s .post method and another Zend action which is set to take in JSON and only return a JSON string.

JQuery is used to generate a simple single column table and add two links to the page. The first link “Add New Visit” will add whatever is in the textbox to our very simple single column table. The second link “Save to Database” will update the database with the values of our table by calling the SAVEDATA action on the VISIT controller. The SAVEDATA action takes in a JSON string, does something to the database and returns a JSON string to the client. The possibilities that result from passing JSON between client and server using this JQuery method are amazing and make it trivial to create AJAX interfaces with JQuery and Zend.

IMPORTANT: I had to include the well known json2.js script by Douglas Crockford in order to get my JSON encoding and decoding working correctly in all browsers. This script saved a lot of headaches and is only 17k (and can probably be minified).

In the view, in the <script></script> at the top we first need to add in the JQuery that will be loaded on document ready (standard JQuery practice):

$(document).ready(function(){
  // create the two links to "Add New Visit" and "Save to Database" and place before statusmessage div
  $( "div.statusmessage" ).before("<a href='#' id='addvisitbutton'>Add New Visit</a>&nbsp;&nbsp;<a href='#' id='savedatabutton'>Save to Database</a>");
  // create the empty simple one column table to store our visits and place it after the statusmessage div
  $('div.statusmessage').after("<table id='visittable'><tbody><tr><th>Visit Name</th></tr></tbody></table>");
  // handle "Add New Visit" button click
  $( "#addvisitbutton" ).click(function() {
    addvisit();
  });
  // handle "Save to Database" button click
  $( "#savedatabutton" ).click(function() {
    savedata();
  });
}

Note that the click handling functions that have been added to the 2 links call either addvisit() or savedata(). These 2 functions are described above and outside the JQuery $(document).ready() as follows:

function addvisit(){
  // get a JSON object from the value of the hidden data field (will be empty initally)
  var jparsed = JSON.parse($("#hiddenjson").val());
  // create a new row to add to the JSON data based on the contents of the text field
  var row = [$("#coughscore").val()];
  // add the row to the end of the table
  jparsed.push(row);
  // set the hidden value to a JSON string representing the contents of the JSON object
  $("#hiddenjson").val(JSON.stringify(jparsed));
  // remove all rows from the visittable table of class "datarow", all new data rows will be of this class
  $("#visittable tbody tr.datarow").remove();
  // iterate through the JSON object  and append the data rows to the visittable table
  for(var i=0;i<jparsed.length;i++)
  {
    rowstring += "<tr class='datarow'>";
    var obj = jparsed[i];
    for(var j=0;j<obj.length;j++)
    {
      rowstring += "<td>" + obj[j] + "</td>";
    }
    rowstring += "</tr>";
  }
  $("#visittable tbody").append(rowstring);
}

When a row is added to the table the hidden field is updated to contain a JSON string describing the whole table. It is this JSON string that is passed to the SAVEDATA action of the VISIT controller by the savedata() function’s .post(), where it is converted to an object by some simple PHP code and then stored in the database:

function savedata(){
  // get the host name and correct controller url using a little Javascript/PHP and the built in Zend url() function
  var host = 'http://' + window.location.hostname + '<?php echo $this->url(array('controller'=>'visit'),"",true); ?>';
  // get the JSON string stored in the hidden field
  var jsondata = $("#hiddenjson").val();
  // use JQuery's .post() function to post to the Zend SAVEDATA action on the VISIT controller
  $.post(host+"/savedata",{
    // send the value of the jsondata variable (the JSON string) in the POST as "jsondata"
    jsondata: jsondata
  },
  // handle the returning JSON data from the SAVEDATA action
  function(data)
  {
    // convert the returning JSON data to an object using .eval()
    obj = window.eval(data);
    // set the value of the statusmessage div to the 'notes' field in the JSON returned by the SAVEDATA action
    // (this is either "Succcess" or "Failure" in this example)
    $('.statusmessage').html(obj['notes']);
  },
    "json");
  }
}

The SAVEDATA action is a standard Zend action on the VISIT controller with the addition of a couple of important lines of code to avoid rendering a view:

public function savedataAction()
{
  // disable the Zend layout
  $this->_helper->layout->disableLayout();
  // suppress auto-rendering and displaying a view
  $this->_helper->viewRenderer->setNoRender();
  // retrieve the jsondata string from the POST variables
  $jsondata = $_POST['jsondata'];
  // create an object to store the success or failure message strings and return them to JQuery.
  $data['notes'] = "";
  // decode the JSON string and turn into an object
  if($dec = Zend_Json::decode($jsondata))
  {
    // do important things with the converted JSON object, e..g write to database etc..
    //
    // set the return message to Success
    $data['notes'] = "Success";
  }
  else
  {
    // conversion from JSON string to PHP object failed, so return Error
    $data['notes'] = "Error";
  }
  // encode the returning object into a JSON string
  $json = Zend_Json::encode($data);
  // echo the JSON string back to JQuery, where it is handled according to the definition in the .post() function
  echo $json;
}

So now you can pass JSON objects between the client and the server using JQuery and json2.js. In this example JQuery is used to populate a table client-side and then pass the data for storage in the database on the server.

Alternatively you can use a Zend action and a JavaScript function to pull data from the server and display it as a table. This is really useful for displaying tabular data and is just a modification of the method above. The JavaScript function retrievedata() to pull data from the server using a new RETRIEVEDATA action and JQuery’s .post() function and add it to our visittable table is as follows:

function retrievedata(){
  // get the host name and correct controller url using a little Javascript/PHP and the built in Zend url() function
  var host = 'http://' + window.location.hostname + '<?php echo $this->url(array('controller'=>'visit'),"",true); ?>';
  // get the JSON string stored in the hidden field
  var jsondata = $("#hiddenjson").val();
  // use JQuery's .post() function to post to the Zend RETRIEVEDATA action on the VISIT controller
// note that we don't actually post any data this time, we only retrieve data
  $.post(host+"/savedata",{
  },
  // handle the returning JSON data from the RETRIEVEDATA action
  function(data)
  {
    // clean up and convert the returned JSON to a string
    // (this step required as sometimes Zend JSON is not always "correct")
    var json = JSON.stringify(data);
    // convert JSON string to object
    var jparsed = JSON.parse(json);
    // create a blank string ready to store a single html row of the table
    var rowstring = "";
    // iterate through the JSON object adding the html for a row of the table each time
    for(var i=0;i<jparsed.length;i++)
    {
      rowstring += "<tr class='datarow'>";
      var obj = jparsed[i];
      // iterate through each column of the row, adding the html for a table cell each time
      for(var j=0;j<obj.length;j++)
      {
        rowstring += "<td>" + obj[j] + "</td>";
      }
      rowstring += "</tr>";
    }
    // append the newly formed rowstring to the table
    $("#visittable tbody").append(rowstring);
    // set the hidden field to the JSON string
    $("#hiddenjson").val(json);

  },
    "json");
  }
}

The RETRIEVEDATA action (simplified to remove database queries) looks like:

public function retrievedataAction()
{
  $this->_helper->layout->disableLayout();
  $this->_helper->viewRenderer->setNoRender();
  // get array of objects from database using ORM
  // alternatively, use standard SQL connection etc etc
  // e.g. $arr = SomeORMMethod("visits");
  $output = array();
  foreach($arr as $key => $value)
  {
    $row = array();
    $row[0] = $value->visitName;
    $row[1] = $value->visitDate;
    $output[] = $row;
  }
  $json = Zend_Json::encode($output);
  echo $json;
}

You may have noticed that all of this can be done without Zend at all. If you read the JQuery .post() documentation it becomes a bit clearer, especially if you end up not using JSON at all. I know there are other methods out there to do this, but since I’m heavily involved with Zend at the moment I thought it would make sense to try and explain this example, as I used it in my own code. Also note, there is no security at all on this example; you will need to manage sessions, use encrypted data etc to make this secure.

The basic framework of JQuery/JSON/Zend means you can easily create rich MVC apps with AJAX and the flexibility of JQuery means that you don’t even have to use Zend at all! You can apply the same basically identical approach with Microsoft MVC, CakePHP or even with your own frameworks, all you need to do is modify the actions.