views:

1134

answers:

4

I'm using Spring, but this question applies to all JSP-controller type designs.

The JSP page references data (using tags) which is populated by the corresponding controller. My question is, where is the appropriate place to perform formatting, in JSP or the controller?

So far I've been preparing the data by formatting it in my controller.

public class ViewPersonController extends org.springframework.web.servlet.mvc.AbstractController
{
    private static final Format MY_DATE_FORMAT = new SimpleDateFormat(...);
    protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response)
    {
        Person person = get person from backing service layer or database
        Map properties = new HashMap();

        // No formatting required, name is a String
        properties.put("name", person.getName());

        // getBirthDate() returns Date and is formatted by a Format
        properties.put("birthDate", MY_DATE_FORMAT.format(person.getBirthDate()));

        // latitude and longitude are separate fields in Person, but in the UI it's one field
        properties.put("location", person.getLatitude() + ", " + person.getLongitude());

        return new ModelAndView("viewPerson", "person", properties);
    }
}

The JSP file would look something like:

Name = <c:out value="${person. name}" /><br>
Birth Date = <c:out value="${person. birthDate}" /><br>
Location = <c:out value="${person. location}" /><br>

I know that JSP does have some provisions for formatting,

<%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt" %>
<fmt:formatDate type="date" value="${person. birthDate}" />

But this only works with Java's java.util.Format. What if I need more complex or computed values. In such a case putting the code in the JSP would be cumbersome (and ugly).

I'm curious if this is following the spirit Spring/JSP/MVC. In other words, is the controller part of the view? Where is the preferred place to perform view related formatting? Should my controller just be returning the object (Person) instead of a Map of formatted values?

+3  A: 

JSPs typically do not have a lot (or any?) code in them, so your options would be

  • controller
  • tag libraries

I would say that a tag library would probably be what you want for most cases, because typically the view is the code that cares about things like formatting.

If standard tag libraries don't get you there, they are not hard to create, so you can roll your own.

davetron5000
+1  A: 

I typically do formatting, etc. in the bean or a view "helper". This has several advantages including the following:

  1. Easier to test
  2. Flexibility to change your view technologies without worrying about porting or rewriting what you've done in custom tablibs.
  3. Cleaner and easier to maintain controller and view code.
digitalsanctum
A: 

The way I would do it is -

an instance of the Person class would be the only object in the Model of the ModelAndView

I would move the "presentation logic" into the Person class itself. For example,

public class Person {
    public String getLocation() {
        return this.latitude.concat(", ").concat(this.longitude);
    }
}

I think overall this approach: 1 - strengthens your domain model. 2 - reduces code duplication (what if you wanted to show the location in another JSP? With your approach you'd have a lot of code duplicated)

bpapa
But this would violate keeping the view separate of the model.
Steve Kuo
That's debatable. You're getting a string representation of a property that can be used anywhere. And most importantly you're getting less code, and it's in a centralized place that makes sense.
bpapa
I would say a true "violation" would be if getLocation returned a string that had HTML tags in it or something.
bpapa
+1  A: 

I prefer to consider formatting part of the display layer, thus done in the JSP. I used Velocity most recently, but same idea with JSP: controller returns a data model, and the view is responsible for rendering that data into a visible representation. Plenty of JSP tag libraries out there for common needs.

You mention complex or computed values. Those sound like elements of the results data model to me, so should be done in the controller, even if they can in principle be determined by other data, such as sum, max and other aggregate values. By formatting in the view I mean basic things like date and number formats, line splitting, alignment. Of course the exact line between data and formatted representation depends on the application, but I think you get the idea.

Dov Wasserman