Another Java Rest framework

If you’re a somewhat experienced Java developer I guess you’ve encountered a lot of framework when it comes to write web services.

Restx.io is a new kid on the block leveraging high velocity with a focus on testability through a set of unique and great features :

  • each rest endpoint generates its documentation from its tests (real killer feature here : we hate writing docs but we live writing tests!)
  • a built in monitoring engine
  • everything that can be done at compile time is done at that time (annotations / dependency injection)
  • it is written in good old plain Java (IDE support : I’m looking at you Play Framework!)
  • auto compile (we don’t like waiting!)

I’ve tested it on a few small projects, I can’t wait to try it on a real project !

Packt Publishing is actually discounting the full range of their eBooks and videos by 50 percent until October 17th using this discount code : COL50.

It can be a good opportunity to check “Instant Apache Wicket 6” which I reviewed a few weeks ago for the newcomers to Apache Wicket. Another good deal could be checking out the best-seller title “Mastering Web Application Development with AngularJS”!

Head over to Packt Publishing site and pick the books of your choice using the promo code COL50.

When you're developping Web applications, you often ask yourself what does your beautiful design will look like if your users enter a very long text. Or you may want to prototype a new screen based on an existing one, I came around a quick hack using HTML5 goodness: content editable !

On the page you want to edit, open your JavaScript console (Cmd+Alt+I on Chrome Mac), and enter the following

  document.body.contentEditable = true;
  

Now you can freely edit the text on your page, once you're done, you can switch off the content editable mode setting the property to false !

Maven

At SRMvision, we develop with localization in mind. We don't have any user visible text that is not in fact tied to a java property file. Quickly, the problem that we faced was the difficulty to keep every language file in sync (and to tidy things up). We developed a small Maven plugin allowing us to ensure that our two main problems are now gone : merge-properties-maven-plugin.

Quick example

I think the easiest way to understand how it works is to explain it with a real use case. Let's say we have a module named Zones in our application, it will lead to create four files (if we are localized in two different languages) :

  • l10n/Zones_en.properties
  • l10n/Zones_fr.properties
  • help/Zones_en.properties
  • help/Zones_fr.properties

As you might have guessed, we have got two different categories of target files, one for the application's localization, and the other one for the application's help. There is only one rule when it comes to filling these files, the property keys must begin with the name of the file, otherwise the build would fail. In this example, every key must begin with the prefix "Zones.".

At the end, we want to get two resource bundles, so we set up the build to do so :

By reading this configuration section you can view almost every single option available in the plugin. You can exclude files from automatic key checking : in the example the files Global_*.properties will not be checked. It allows us to group commonly used keys without needing them to begin with the correct prefix (it also eases migration for legacy code, breaking the build would be too intrusive).

You can also notice that we use a Maven property to enable the fail on count mismatch functionality of the plugin, with the help of Maven profiles, we can set it to false for development and to true for continuous integration and translation team. When this configuration is used you will get an output like the following in your Maven build :

If the build should check consistency in merged files and if it does not match, it will output blank keys as well as lonely keys in order for your translator to fix it easily.

Bonus feature

We use Java's MessageFormat to format our translated string, one of the thing we tend to forget is to escape the single quotes in our translations. The plugin does this magic for us, it automatically adds the missing single quotes in every messages.

playlogo

I was having a strange issue with localization in a Play Framework application. I followed the simple steps detailed on the official documentation but with no luck.

When experimenting, I figured out that the locale used is the default locale of the JVM. In my case, my default locale is French so I only had French in my application. But on Heroku, the default locale is English and thus the application was only working in English.

The trick consists in adding an implicit lang to your template views. In fact, Scala import an implicit lang with the lowest priority being the one coming from the JVM, if you want to get the language parsed from the Accept-Languages http header, you need to add an implicit as below :

@(title: String)(content: Html)(implicit lang: Lang)

With this little trick, your calls to localization will use the locale extracted from the http request as expected.