Spring Web MVC utilizes the ModelAndView class to encapsulate the M and V of MVC. The model part is simply a map of objects associated with a request. The key is the string name that you will use to access the object via the tag libraries. Placing an object with a key of “userPrefs” into the map will make the UserPrefs object available to the HttpServletRequest and eventually part of the implicit request object that is part of JSPs. In order to display any user data in a JSP it has to be part of the request object and it gets there by placing it in the Map used by ModelAndView.

In my experience with Spring Web MVC I’ve found that most form controller classes extend SimpleFormController. SimpleFormController derives most of its lifecycle from AbstractFormController, which provides us with a few interesting methods. There is one method in particular that is interesting. The referenceData(HttpServletRequest request) method returns a Map and this method is called during the showForm(…) method. showForm returns a ModelAndView object which will include whatever data is included in the Map returned by referenceData. The default implementation of referenceData returns null, so we have to override it in our class that extends SimpleFormController.

Here is some example code from my controller class which extends SimpleFormController. The point here is to provide a list of Bookmark objects to the form for a user to delete.


@Override
protected Map referenceData(HttpServletRequest request) throws Exception {
List userBookmarkList = bookmarkService.getUserBookmarks(
request.getUserPrincipal().toString());

Map model = new HashMap();
model.put("userBookmarks", userBookmarkList);
return model;
}

This is pretty simple example. It’s first getting the user from the request object. This is an authenticated session where a user has provided a login name and password. That name is retrieved from the request object and used to get a List of all of their bookmarks. The List is then put into a HashMap with the key “userBookmarks”.

After referenceData returns the Map those entries are then passed on to the view by the showForm method. We can use a couple JSTL tag libraries to iterate over the list and display each bookmark while building the form. The following is an excerpt from the view (NOTE – This is pre-Spring 2.5):

This view uses two tag libraries, one from JSTL, the other being the Spring form tag library. Within the form tags the JSTL forEach tag is used to iterate over the list of bookmarks. The list is obtained via the ${userBookmarks} variable. This calling convention takes advantage of the search order for finding request parameters used by JSTL. Part of the search includes looking in the request object that is part of every JSP. The items attribute is the object we want to iterate over, that being the object keyed by userBookmarks.

That object is the List of bookmarks we got from the business tier. By iterating over the bookmarks we have access to each Bookmark object and each of it’s fields. The checkbox tag is used to build up the HTML view of the each bookmark with a check box next to it for the user to click. When the user is done selecting bookmarks to delete the onSubmit method is called back in the controller.

So how does Spring know which bookmarks have been checked in the form? The form object bound to the form keeps track of the checked bookmarks. This form object is very simple, it encapsulates an array of Strings and provides a getter and setter for the array.


package net.anthonychaves.bookmarks.dataobject;

public class DeleteBookmarksForm {

private String[] bookmarkIds;

public void setBookmarkIds(String[] bookmarkIds) {
this.bookmarkIds = bookmarkIds;
}

public String[] getBookmarkIds() {
return bookmarkIds;
}
}

The “value” part of our checkbox contains the bookmark ID. When the checkbox is checked and the form is submitted the Spring dispatcher servlet collects all of the checked values of the same path into an array and puts them into the DeleteBookmarksForm object. The form object is then passed to the DeleteBookmarksController via the onSubmit method. We don’t have to implement the entire onSubmit method, though. The default implementation calls doSubmitAction which takes only our command object, in this case DeleteBookmarksForm, as an argument. Once we have a list of bookmark IDs to delete we can call the business tier to remove them from the database (after appropriate error checking, of course).

Spring 2.5 introduces the form:checkboxes tag which eliminates the need to use the JSTL forEach tag to iterate over the list of objects. The checkboxes tag takes care of that for you.

There is more to working with lists in Spring Web MVC than the material presented here. I’ve included a few references below in case you’re interested in finding out more. Thanks for reading and as usual let me know if you have any questions or comments!

Business logic always belongs in its own layer. Why? Business logic is the thing that makes your application what it is. It doesn’t matter how it’s dressed up – web app, desktop app, web service – the business logic accomplishes the task the user wants to perform. Business logic is your application. Because of its importance business logic should be placed in a sacred place where it will not be disturbed by presentation logic or infrastructure underpinnings – the business tier. Separating the business concerns from all other concerns buys a lot of benefits for the development team.

What if aggregate data must be displayed in multiple locations? For example, shopping cart data could be displayed on a checkout screen and also as a side bar while the user is still shopping. In an action-based framework this code would be duplicated in two different actions. It would be present in the action that generated checkout screen and again in the action that assembled the shopping view screen. Rather than duplicate the code why not make a method call into the business layer that did the same thing? The end result is the same except it separates the concerns of web and business logic.

Refactoring this code into a business tier method helps make our application more loosely coupled. Loose coupling is important for business logic because it allows for easier reuse, testability and maintanence. If the business logic is located in the action then creating a web service around it is going to be more difficult. The business logic will have to be decouple from the web action and pulled into a layer where both the web action and web service can use it. A good example of this would be a web page that displays new items available to a customer. A web page is ok but the customer would have to keep checking back for updates. An easier way to publish this information would be to make it available as an RSS feed the customer can subscribe to. Duplicating the logic to get the new items isn’t particularly difficult, but why make maintenance more difficult than it has to be? The application should be refactored to have a business layer that is responsible for getting the data which can be called by two different locations in the presentation layer (the web tier and the RSS feed creator). Testing the business logic (you’re testing, right?) and bug fixing only have to be done in one location thanks to this refactoring too.

Another quote from the thread is, “The other side of the story is that to have two separate classes, one dealing with the http/web layer (ex: UserAction) and one dealing with the business logic layer (ex: UserService) is bureaucratic.” This statement shows a lack of understanding of functional decomposition. Each module should be responsible for one and only one thing. If the web layer is for dealing with actions then actions should only be dealt with in the web layer. If the web layer is for dealing with actions then business logic should not be dealt with at the web layer. Business logic belongs where it can remain undisturbed by other concerns. Tight coupling of these concerns makes testing more difficult because it requires testing everything it once rather than testing in isolation. Because your application is only as good as the business logic the business layer should have a test suite that can be run without depending on action or presentation logic.

There are plenty of other reasons you should keep business and web logic separate. This is in no way an exhaustive list, but it’s certainly something to think about. If you’re building any professional application then business logic should always be in its own layer. Not only will your boss/team/successor thank you for it, it’s good software development and you’ll thank yourself for it too.

The reason we have bug triage sessions in the first place is no one has bothered to talk about these bugs before dealing with the entire list became a high priority. Everyone pays the high price of brutally long bug triage sessions because the low price of communicating on a consistent basis hasn’t been a priority right along. In order to make triage sessions more valuable you have to make it your top priority to get to the meeting with the fewest, highest quality bugs possible. This doesn’t mean close all the small bugs before the meeting and hope no one notices or to assign them all to someone else. It means effectively dealing with bugs while they’re incoming. In order to do this right you’ll need to build a relationship with someone in QE. Yes I know QE and developers are supposed to be like cats and dogs or water and oil. In this case the relationship needs to be more like peanut butter and jelly. Or peanut butter and chocolate. Or peanut butter and whatever else you like since it goes well with just about everything. You need to be like peanut butter.

Part of the beauty in doing this is that your chosen QE co-conspirator doesn’t even need to know they are a co-conspirator, though eventually they will realize their job has become much, much easier to do effectively. One of your goals is to stop bugs from coming in by stopping them at the source, which means you need to get QE to reduce the number of bugs filed on your software. There are a few ways to go about this and not all of them are good. Some can even get you in trouble with HR. If you want to reduce the number of incoming bugs you have to first find out what software QE is testing. If you’re late to the game then you should start just after the code is released to QE, though starting any time is better than not starting at all. In order to find out what’s going on in QE you have to, gasp, talk to someone in QE! It’s true, they know how to communicate using spoken language, not just Bugzilla. You can ask your QE person, “hey, how’s it going?” and they will tell you everything is going fine, testing is going fine, day to day tasks are going fine and then move on to filing more bug reports on your software. Or you could ask, “hey <QE person>, have you had a chance to look at <my software module in question>? If you have a chance I’d like to go over the work I’ve done with you in order to answer any questions you have on it.” The second way always gets better results than the first and it’s surprising how very few software engineers are capable of doing this. Asking the question in this way sets up a discussion by showing the QE person that you are open to questions and feedback. It gives them assurance that their input is valuable because it is! If they’re testing software and they don’t understand what it’s doing they’re not going to be responsive to the first question of “how’s it going” unless they have an ax to grind. You’re not going to get anything useful out of that question because it gives no indication that questions or constructive criticism are welcome even if they are. Do you really want to reduce your bug count? Spend a half hour going over your work with them. Answer every question they have and go over the implementation. Draw diagrams, play charades, do everything you can to help them understand what you’ve unleashed. All of those bugs that are really just setup and configuration questions will be vaporized if you do this. Ditto for the “what does this software actually do” bugs that would have been filed. You have just taken the first step to reducing the number of low quality bugs you have to deal with.

I remember an iteration where I had a fairly high profile deliverable. I felt like I nailed the business requirement. All the features were complete and robust. The implementation was impeccable. This deliverable was a feature that had been lacking for a long time and I had a feeling that I’d be heralded as a hero for delivering just what everyone was begging to have for such a long time. I didn’t think anyone would be able to open even a single bug on my project. How could they? They would be too busy drooling over the amazing quality of what I just delivered.

Imagine my surprise when QE started opening up bug after bug after bug on what most people in development considered perfection. I watched in panic all day long as I saw my bug list get longer and longer. And almost everyone one of the bugs was shallow. The QE person didn’t dig very far at all for a reason to file a bug. If they didn’t understand what was supposed to happen they filed a bug. If they thought the software was supposed to do something and it didn’t then there was a bug. If they thought the software should have additional features they considered nice to have there was a bug. Needless to say that iteration’s acceptance process was very stressful for me. That’s when I realized the value in stopping bugs at the source.

Almost all of the bugs were in the class that would have gone away if I just communicated what was going to happen before the release. Fast forward to the next iteration. Once again I was working on high profile features that should be a slam dunk as far as quality goes. The week before it was released to QE I asked around to find out who would be testing my features. I scheduled a meeting with them to talk about my deliverable and give them a demo. In my meeting invite I sent a brief description of what I wanted to talk about and encouraged them to show up with questions or relevant topics to discuss. During the meeting we went over just about every facet of every feature in great detail. We went over how to configure the operating system environment, the topology and the application. I wanted to do everything in my power to make sure they had all the information they needed to meaningfully test my software. Meaningless bugs are a waste of everyone’s time. Once the software was officially released to QE I didn’t see a single bug filed on the first day of testing. One was filed on the second day of testing. None on the third. I had only a handful of bugs for that iteration’s release because I made sure to discuss my concerns with QE before they started testing it. I also had more time to concentrate on the meaningful bugs.

On Monday we’ll talk about what to do with the bugs that are already in your queue. If you found this worthwhile please forward it on to anyone else you think would find it helpful.