Question

In a Spring MVC webapp, I have a form and a corresponding controller. In the controller, I need to know if the user changed any values in the form, so that I know whether to update a “changed_on” column in a status table in my database.

I don’t care to know which field changed, and I’ll save the user’s data regardless. But if the user changed A->B and then back to A before they submitted, I don’t want to consider that a change. I only want to update the date/time column if the user is actually changing data, because I need to know at a later point when the user last changed their data.

What’s the best way to achieve this? Is it better to do it on the back-end, or the front-end? This seems like a very general problem: how to tell if the user is changing data on a form.

I’ve come up with a few potential solutions. My form fields are booleans, integers, strings and enums.

Front-end solutions

1. Set a hidden form field using an onChange or onBlur listener in Javascript.
2. Use a jQuery callback function with $("form :input").change(), and use .data() to set a changed value to true.

Back-end solutions

1. In the form class that the web form is bound to (via @InitBinder("formName") in my controller), override hashCode() based on all of the fields I’m interested in monitoring for a change. Because I’m not using my form classes in any collections, or passing to Hibernate, I don’t envision any bad side effects of this. Here’s an implementation using Guava:

   @Override
   public int hashCode() {
       return Objects.hashCode(this.field1, this.field2, etc.);
   }
   

   Then I can compare the old form object (created in the get() method) with the new one created by the WebDataBinder from the submitted form values. If the hashes are different, then the user changed something.

   The question I have with this approach is, how do I keep the old form object around? Is there a way to stuff it in the page’s ModelAndView, that will survive from the GET to the POST? Or could I just re-create it in my doPost() method, by reloading the persistent entity that’s based on from the db? If Hibernate caches my entities, then re-creating the original form object – before persisting any new changes – should be pretty quick.

2. Similar to #1, but using reflection instead of a hard-coded reliance on individual fields. This way, if any new form fields are added, we won’t forget to add them to the hashCode() method. Here’s an implementation:

   public static boolean hasFormChanged(Object form1, Object form2) {
       return HashCodeBuilder.reflectionHashCode(form1) != HashCodeBuilder.reflectionHashCode(form2);
   }
   

   Now, I know that reflection is slow; in my tests, about 8-12x slower than the Objects.hashCode() approach above. However, I only have ~4 form fields, and in tests on my local machine the reflection-based method is taking about 3.5 microseconds per call. The other downside of reflection is that we’d need to be mindful of adding any new instance variables to the form class (or its parent class(es)), that we don’t want to include in the comparison.

Answer 1

For front end solution, you can implement more generic example, which can be applied to any page. On page load, iterate over form elements, then iterate over every field of the form and save its names and values

For example,

["form1", {field1: "value1"}, {field2 : "value2"}] etc

Right before submit, you can check whether new form values are equal to old form values, and add additional property “changed”

Every front-end solution is ugly. Of course better to make it on server-side

You can store old object in httpSession, or you can request it second time (note hibernate does not use cache by default). What is the sense of using hashCode instead of equals ? There a small possibility of collision, when not the same objects return same hashCode

The most straightforward approach – request your object second time from Db, and use equals to compare them