Using Spring MVC for object oriented templating!

There is no secret that programming java in object oriented style is much easer with the Spring Framework.

But what about writing templates for the various rendering issues we have? Right now it is quite complicated to write a JSP template without violating dry. In fact the structure of jsp templates looks more like programming in a procedural way. There are frameworks available which reduces the problem - but mostly by introducing a new complexity through extra configuration.

By using <jsp:include ... > you need to tell which exact template should be included. Of course we could calculate the template name though the business logic - but you mix up template with business logic by that solution.


In the following I'd like to draw a concept which lets you write templates in object oriented style together with Spring MVC. This concept tries to take advantage of what is known as convention over configuration to simplify use.

The main key of the concept is that it uses the type hierarchy of an object instance to find the right template which should be used to render the view. In the following this object instance will be called self.

Suppose you have a class like this:

public class Vehicle {
    public Foo getFooForBar() {...};
}

Then the type hierarchy of this class would be quite simple. It consists of the type Vehicle and java.lang.Object. Any instance of type Vehicle can be the self instance. The ViewResolver which implements our concept takes the type hierarchy of this self instance and tries to find the view to render by going through that hierarchy.

It will first try to find a view with name Vehicle.jsp. If you don't have a view with that name the next type in the type hierarchy will be used to find the view. In this case it would be the View java.lang.Object.jsp.

When the view resolver finds the template it will render it and places the self instance into the model for the template. So you could access self through:

<c:out value="${self.fooForBar}/>

Personally I like it to have a template with name Vehicle.jsp. Because that makes it simple to locate which java type implements the contract for this template.

To avoid long package names in the view name it is possible to place the templates into folders which corresponds to the java packaging system: java/lang/Object.jsp. An other variation could be to use the package name as a single folder: java.lang/Object.jsp.

Please note that the type hierarchy also include the interfaces your class implement! So you could also define a view for an interface.

Since we don't have only a single view for our Vehicle type we can give a view parameter to the ViewResolver. The view parameter is simply a string. Suppose you want to render a Vehicle instance for the view foobar which is included in an other view:

Type FooWithVehicle:

public class FooWithVehicle {
    public Vehicle getVehicle() {...}
}

Template FooWithVehicle.jsp:

<x:include self="${self.vehicle} view="foobar"/>

The include tag again uses the ViewResolver to find the right template for the instance which is returned by FooWithVehicle#getVehicle(). In a complex type hierarchy that could by a Vehicle or any subtype of it. The ViewResolver now uses the given view foobar to look for a specific view of our Vehicle instance with a name Vehicle.foobar.jsp. Again if the ViewResolver does not find a view for this name it will look for Object.foobar.jsp.

That is the main part of the concept - and it should be enough for the moment. Please let me know what you think about it.