Cake Solutions Team Blog » spring mvc

UTF-8 encoding revisited

Jan Machacek — Tue, 08 Nov 2011 09:14:10 +0000

My old post on UTF-8 encoding in Spring messages using the ReloadableResourceBundleMessageSource still receives a lot of attention. However, UTF-8 encoding of the messages is just a part of i18n applications. (It’s called i18n because the word is internationalisation–i, followed by 18 letters, followed by n–did you know?)
Now, the Spring ReloadableResourceBundleMessageSource is usually declared as

The key bit here is, of course, the defaultEncoding=UTF-8 property. This ensures that the MessageSource‘s messages will not be mangled when they are loaded from the files. So far, so good!

I18n web applications

However, the MessageSources are just one part of truly internationalisable web applications. It is very easy for the developers to forget that the messages in some langauges will be much longer than in English; also, some languages are written right-to-left (think Arabic, Hebrew). So, simply using the messages might not be enough for truly internationalisable application.

Views, locales and LocaleResolvers

In Spring MVC (and Spring Mobile), we define a sequence of ViewResolvers and LocaleResolvers, which together determine which view to display. The code in our controllers can remain oblivious of the users’ locales:

@Controller
class UserController @Autowired() (private val userService: UserService) {

  @RequestMapping(value = "/users/{id}", method = RequestMethod.GET)
  def view(@PathVariable id: Long, model: Model) = {
    model.addAttribute(userService.findUserById(id))
    "users/view"
  }

}

(Notice that I’ve sneaked in Scala to our Spring application, but the Java code would look almost the same!) Now, the method view returns a String. That string now needs to be turned into a View and, together with the model, become the familiar ModelAndView object.
The ViewResolver and LocaleResolver do just that. (It is more accurate to say that we have an ordered sequence of ViewResolvers and LocaleResolvers; and whichever ViewResolver or LocaleResolver first resolves the view or locale will be used.)
We can include the messages loaded by the MessageSource in our views (say, JSPs for simlicity) using the familiar Spring forms tag library:

<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>

…

:  ...

That is simple to see. But where to put the JSP? We can start by keeping it in the the-webapp src/main/webapp/WEB-INF/views followed by users/view.jsp. I’ve separated the path on purpose: we can see that there is some kind of prefix (/WEB-INF/views), followed by the view name, followed by some suffix (.jsp). That is, in fact the configuration of the typical InternalResourceViewResolver.

Excellent. Our controller code works, the messages are happily being loaded with the correct encoding.

Wide internationalisation support

Unfortunately, there is a serious flaw in the structure I showed above. The HTML from the JSP above is going to display

Edit user: username …

in English (assuming the edit-user says “Edit user” and username says “username” in our messages bundle). It will still work reasonably well in Czech, showing

Upravit uživatele: uživatelské jméno …

(again, assuming the correct translations in the messages bundle).
But what will happen in Arabic? Or Hebrew? Sure, we can create the appropriate transalations in the messages bundle, but remember, Arabic is right-to-left. And what if the Arabic text is far longer than the English or Czech one?
It turns out that you need to structure your views differently; and that you need to modify the chosen ViewResolver to take the new structure into account. At first, I thought that I should have directory structure under WEB-INF/views for every locale, with fallback rules ensuring that I end up using the en_GB locale in the end. But that was confusing. Why should the Czech localisation use JSPs from the en_GB directory?
The most helpful structure I found is to have the following view structure under WEB-INF/views:

ltr
  user
    view.jsp
    edit.jsp
    add.jsp
  …
rtl
  user
    view.jsp
    edit.jsp
    add.jsp
  …
tr_TR
  user
    view.jsp

In this example, I have all files for the left-to-right languages and right-to-left languages and I also have a special case for the view user JSP in Turkish.

Summary

Such a structure gives you the most flexibility, and keeps the number of files and directories in your web applications in check. The only work that’s required on your part is the modification of your chosen implementation of the ViewResolver.

Guess what?

Jan Machacek — Thu, 17 Jun 2010 20:25:07 +0000

With the fantastic weather outside, I needed to take a break in my training. My legs felt very tired this morning and my heart rate just would not go above 155 bpm: all the signs to take a rest day. Now, rest day for the legs does not mean rest day for the brain! And so, I put some more pages to the Beginning MVC chapter. Download here.

Oh, and one more thing. I spoke to Gregory from Mulesoft today and we had an interesting chat about OSGi. I will add my thoughts about this soon, in the meantime read Ross’s post at http://rossmason.blogspot.com/2008/04/osgi-is-irrelevant.html.

More Open Spring 3 MVC goodies

Jan Machacek — Tue, 15 Jun 2010 17:36:32 +0000

I have been very busy indeed, but managed to find some time to add more text to the Beginning Spring MVC chapter of Open Spring 3. Get downloadin’!

Open Spring 3 updated

Jan Machacek — Wed, 28 Apr 2010 16:48:11 +0000

Good news everyone! I’ve added a few pages to the Beginning Spring MVC chapter of the Open Spring 3 book. Download here for your reading pleasure!

Open Spring 3

Jan Machacek — Sat, 03 Apr 2010 09:42:58 +0000

Chapters for download are:
Beginning Spring MVC

I was thinking about the name of our new “unbook”. The “Pro” series are in the domain of Apress, the “In Action” books are published by Manning; I don’t know what O’Reilly call their books, but I wanted to make sure I don’t step on anyone’s toes.
In line with our advocacy of the open source, I decided to call the book Open Spring 3. I wanted to emphasise that it is a continuation of our Pro Spring series (in terms of scope and, I hope, quality and popularity), but that is is fundamentally different from the traditional printed books. And so, we give you Open Spring 3.
Open Spring 3 is just the first one in what we hope will become a series of other books, all covering various open source technologies and all available for free (both as in speech and beer) online.

Spring MVC on the iPhone

Jan Machacek — Thu, 25 Mar 2010 16:03:34 +0000

…and, as we discovered at the Open Source User Group meeting on 24th March, also on the iPod Touch!
If you’d like to explore in detail the application I used yesterday, download it from GitHub. The webapp uses, as the headline suggests, Spring MVC (with particular focus on ViewResolvers), and alongside the bog-standard JSP code, exploits jQTouch to make the iPhone/iPod Touch interface look very native app-like.
Alternatively, if you don’t want to get messy with the source code, you can just download the Spring MVC iPhone Slides.

Spring and iPhone

Jan Machacek — Mon, 15 Mar 2010 11:36:07 +0000

The talk for next week’s open source user group is ready. I will give brief overview of Spring 3 MVC and explain how to create native-looking iPhone web application using as little code as possible.
It would not be a proper user group talk without a live demo, so bring your good selves with your iPhones and we’ll create a Spring MVC application that looks just amazing on the iPhone, all within about 25 minutes!
Figure 1 shows what we will achieve: the iPhone will send a request through the Internet to our Tomcat, where our Spring-driven MVC application is going to process it.

Figure 1. Spring MVC & iPhone

Spring MVC and iPhone

Jan Machacek — Tue, 23 Feb 2010 20:21:54 +0000

I have exciting new talk ready for the next open source user group meeting. We will implement a very friendly iPhone web application using Spring MVC 3.0 in about 30 minutes’ time while keeping the controllers and models completely intact. … Continue reading →

Custom arguments for @RequestMapping methods

Jan Machacek — Fri, 23 Oct 2009 14:22:25 +0000

So, Spring MVC fans, let’s say you have a @RequestMapping-annotated method in your controller, but you would like to include a custom argument, in addition to the standard ones like Model, HttpServletRequest, and HttpServletResponse.
The solution is to implement a WebArgumentResolver. As an example, we’ll create a CurrentDateWebArgumentResolver; as its name suggests, this resolver will be able to set any Date argument in the controller method to current date.
We have to write

public class ContextExtractingWebArgumentResolver
    implements WebArgumentResolver {

    @Override
    public Object resolveArgument(MethodParameter methodParameter,
        NativeWebRequest webRequest) throws Exception {
        if (Date.class == methodParameter.getParameterType()) {
            return new Date();
        }
        return UNRESOLVED;
    }
}

We then wire-in the argument resolver in our Spring application context configuration file:

Once done, we can create a @RequestMapping-annotated method in our controller and include the Date argument; that argument will now receive the current date. For example, we can have

@Controller
public class HomeController {
    @RequestMapping(value="/index", method=RequestMethod.GET)
    public void index(Date date, Model m) {
        m.addAttribute("now", date);
    }
}

The model that will be passed to the view after making a GET request to the /index URL will include attribute named now; the value of the attribute will be the current time.
Naturally, this is just a simple example and injecting current date is not very enterprisey thing to do, but using the approach I have outlined, you can now set much more useful argument types. Do not forget that the implementation of the WebArgumentResolver is a Spring bean, thus having access to all features available in the Spring application context.

Spring MVC Volume II

Jan Machacek — Wed, 21 Oct 2009 12:18:38 +0000

It was my pleasure to deliver my Spring MVC talk at the Java User Group meeting in London yesterday. I loved the audience–they asked the right questions at the right time; at times they were paying too much attention and spotted a bug! Mea maxima culpa, all is corrected now.

The slides and the source code are available at http://github.com/janm399/smvc/tree/master.

I’d love to hear suggestions for the next talk–I am thinking about advanced Spring MVC, where we take a look under the hood of the AnnotationMethodHandlerAdapter and its friends. Alternatively, we could leave the cushy OO world behind and dive into AOP, with focus on [Spring|Dynamic] AOP.

Please comment or tweet to @honzam399.