Web Accessibility Course

Attention fellow web developers! Google is giving a free online course to improve the accessibility of your website/application. While this might not seem like a big issue, the World Health Organization estimates the number of people with visual impairments to be 285 million. You can save them from a lot of frustration, and offer a far better user experience by following a few guidelines.

Making your site more user friendly to blind or low vision people doesn't have to be 'a pain in the ass'. It should come naturally, with a minimum of extra effort. Google will provide techniques and tools, as well as expert guidance to make the world wide web a slightly better place, one site at a time.

Summer of Technology @Contribute

Just like last year, Contribute organizes a 'Summer of Technology'. The concept is as simple as it is nice: free one-day workshops for everyone interested. If you're a developer, architect, ... or just a technology enthusiast, take a look at the sessions we're organizing, and register for the ones that you're interest in.

You'll find the full overview at the Contribute website: http://www.contribute.be/sot

Topics range from Oracle Forms over BigData/NoQSL to version control. Every tuesday, this summer!

Eclipse cannot run program javaw.exe

Yesterday, I checked out a project from SVN, I ran mvn eclipse:eclipse and imported it into my IDE. So far so good, everything compiled, Maven could run all the tests, all was well.

But then I tried to run a JUnit test in Eclipse. I kept getting a strange error about Eclipse not being able to run javaw.exe in my project-folder. After some Googling, I found that the underlying error that causes this problem, was of an entirely different nature: Windows has a character limit to command line statements. And since Eclipse assembles the classpath itself to pass it on as a launch parameter, the command line character limit got violated.

I now knew what was causing the error, but fixing it didn't seem that simple. I tried to remove all unnecessary libraries (there weren't a lot), but the problem persisted. So I changed to drastic measures: I moved my Maven repository to a folder directly at my C:\ disk. The path was about 30 characters shorter than before, but since Eclipse was adding a whole lot of Maven libraries to my classpath, it made a huge difference.

After that, I could run my JUnit test without any problems. I suppose I'm safe for now, but what will happen when we add even more libraries to the project? It's possible that at a given point, the classpath will be too long for even the shortest possible repo-path you can get. And then what? Switching to Linux could be an option, but during my quest to solve this problem, I also read that IntelliJ has better support for this. So going there could be an option too. Or I could just write/wait for an Eclipse plugin that deals with this problem...

Belgium Liferay User Group

Since the Liferay community is ever growing, there are user groups being developed. One of them, is BeLiUG (Belgium Liferay User Group). If you're a Liferay enthusiast, and are based in Belgium, request your membership today!

Of course, if you're not based in Belgium and want to join a Liferay User Group, search for the one in your country and apply. The idea of User Groups is to get together on a regular basis to talk about certain aspects of the product. It's a great way to meet new people, and to learn a few things about a technology you like.

Custom internationalized error messages in Spring MVC + JSR303

A very common thing to do when building an application, is using JSR303 validation annotations on your domain classes. In a Spring MVC controller, those annotated fields will get validated when calling a ResuestMapping method with an @Valid parameter. You can then easily show the generated errors in your Spring MVC form.

So far so good. Only drawback is that Spring has some default messages. Which are clear, but usually not what you want in your frontend pages. Luckily, there's an easy way to override the defaults with custom messages!

NOTE: This small guide assumes you're using Spring MVC's Internationalization in a correct way, as described here. 

Ok, so overriding the messages. Actually, it's fairly easy. If you want to override each and every message for @NotEmpty, you add 1 entry to your messages.properties file:

NotEmpty = This is the new default message for all NotEmpty annotations

Easy huh? Now if you want to be more specific, you can override the message for (for example) every firstname that is @NotEmpty:

NotEmpty.firstname = This is the new default message for NotEmpty annotations on firstname-fields

This will override the default message for every field named firstname. But you can even be more specific! You can define an error message for a specific field in a specific class. If you have an Employee class, with a firstname field that is annotated with @NotEmpty, you can specify a default message like this:

NotEmpty.employee.firstname = This is the new default message for the NotEmpty annotation on the firstname-field in our Employee class

There's one huge point of attention, though. The pattern of your message has to resemble the SPeL-pattern you'd use to access the field. Usually, the @Valid annotation will be on a command object. That means that in this case, our command object has to be named "employee" on the Model. If, however, you have named your command "command", you'll have to change the message key to this:

NotEmpty.command.firstname = This is the new default.

It's a pitfall, and one you can lose a lot of time with!

Liferay: beta languages

If you have used the internationalization built in in Liferay, you might have noticed if you hover over the flags, the name of the languages appears. You also might have noticed, the name indicates the language is 'in beta'. If you want to get rid of this, you can write a hook (or extend a hook you already have).

Of course, you need to know what page you have to adjust. The display of the language-portlet is located in $LIFERAY_HOME$/tomcat-version/webapps/ROOT/html/taglib/ui/language/page.jsp. Copy the page in your hook, and somewhere near the bottom, you'll find following code:

if (LanguageUtil.isBetaLocale(locales[i])) 
{
    message = message + " - Beta";
}

Remove it, and the beta indication is gone!

Special character encoding

If you have ever created a custom language bundle, you'll know special characters can be very annoying. When they're not displaying correctly, but instead showing a diamond with a question mark or a white rectangle, it's sometimes difficult and frustrating to find the origin of the problem.

When you're building a website that has to come with a language with a lot of special characters (French, German, ...), you can run these encoding problems. In fact, there only has to be one of those special characters anywhere in your site, and it'll be messed up. When working with resource bundles (.properties files),  I've found that these few steps often resolve a lot of issues, so try to follow these simple guidelines.

• Make sure your general encoding is set to UTF-8. In Eclipse, you do this in Window -> Preferences -> General -> Workspace
• Each file can have a seperate encoding as well. Check the properties of your .properties files. In Eclipse, you do this by right-clicking, then selecting Properties. Under Resource, you can set the encoding to UTF-8.

Redeploy your application with this correct settings, and your problems should dissolve! Bear in mind, though, that if you had an incorrect encoding first, switching to the correct encoding may break your file and replace the special characters by the 'not found' characters (diamond or rectangle). Check your file before deploying!