Vaadin 7 I18N - part 2

Completing the I18N Picture

For some reason I forgot to post the fact that I did complete the I18N task I set myself.  Perhaps because it was not quite as difficult as I expected.

When I looked at some of the new Vaadin 7 code, I discovered that the FieldGroup class provided much of what I needed.  (FieldGroup is the successor to the Vaadin 6 Form - and in my opinion, substantially better).

So within V7 now is a reasonably complete I18N approach, though seriously lacking in translations.  For that reason I have not yet added a facility in the demo to switch locales.

Vaadin and I18N

With or Without Guice

If you have read earlier posts, you will know that my V7 project uses Guice.  The I18N implementation I have developed so far does not use Guice a great deal and would be easy to extract to another DI framework, or manual injection.

Approach

I was trying to come up with a design that would simplify some of the repetitive nature of coding for I18N support.  I came to the conclusion that I would actually need two methods which can be used together, as the developer decides.  The documentation gives a better explanation, but I've summarised it in this post.

Using Annotations

Annotations would seem to be quite a neat way to support I18N.  It means that the I18N key is defined alongside the component to which it relates.  There are limitations, however, particularly if you are using translations with parameters, as there is no easy way to define the parameter values to be used.

I have completed the implementation of the annotation based implementation, and it works quite well for many circumstances.  That includes nested components which also need I18N support.  Vaadin tables also need a little special handling because of course, the column headings would normally be translatable.

The code for this is still in the develop branch, but has reasonably well tested.

Using field factories

There also seems to be an opportunity to provide I18N support using the FieldFactory approach provided by Vaadin.  I haven't started on this work yet.

Alternative Java MessageFormat

MessageFormat

I was working on providing I18N support in my Krail project, when I was reminded of the strange characteristics of the standard Java MessageFormat class (java.text.MesssageFormat) ... especially the handling of single quotes.

I thought maybe it had been improved in Java 7, but it seems not.  The javadoc still carries a warning:

Warning:

The rules for using quotes within message format patterns unfortunately have shown to be somewhat confusing. In particular, it isn't always obvious to localizers whether single quotes need to be doubled or not. Make sure to inform localizers about the rules, and tell them (for example, by using comments in resource bundle source files) which strings will be processed by MessageFormat. Note that localizers may need to use single quotes in translated strings where the original version doesn't have them.

The Alternative

I remember being thoroughly confused by MessageFormat and the "solution" offered by the javadoc hardly helpful.  So I started looking for an alternative.  I found quite a few posts also looking for alternatives but still no real solution.  

So I wrote one ... it is based on sl4j, who have a highly tuned message handling routine for logging but which requires the parameter values to be provided in the same order as the message parameters.  That makes perfect sense for logging, but does not work very well for I18N, where different languages put the parameter values in different orders.

So I took the easy option of providing my own MessageFormat class to take the parameters in any order, but then organise them so that the sl4j MessageFormatter can do its work.

The resulting code is here, and its companion test code here.  Even if you have no interest in the Krail project, you may find the alternative MessageFormat useful.

OrientDB deployment

Publishing the V7 Demo

Demo now available 

There is now an online demo of V7.

Last minute snag

I has a situation where everything worked on my desktop, but when deployed to a virtual server, connection to the OrientDB database was being refused.  The error I was getting was:

java.lang.IllegalStateException: Node id is possible to generate only on machine which have at least one network interface with mac address.

at com.orientechnologies.orient.core.util.OHostInfo.getMac(OHostInfo.java:48)

at com.orientechnologies.orient.core.version.OVersionFactory.<clinit>(OVersionFactory.java:32)

at com.orientechnologies.orient.core.storage.impl.local.OTxSegment.<clinit>(OTxSegment.java:68)

at com.orientechnologies.orient.core.storage.impl.local.OStorageLocalTxExecuter.<init>(OStorageLocalTxExecuter.java:53)

at com.orientechnologies.orient.core.storage.impl.local.OStorageLocal.<init>(OStorageLocal.java:111)

at com.orientechnologies.orient.core.engine.local.OEngineLocal.createStorage(OEngineLocal.java:44)

It turns out that my OpenVZ virtual private server (VPS) does not allocate a MAC address - which is why the failure occurred.

This does raise the question why a single node database needs a MAC address, but apparently this question had already been asked - the fix for it was in the latest snapshot.

So, I've updated the code to use OrientDB 1.4.0-SNAPSHOT and that problem is solved.

Enjoy the demo (but I will admit it does not look as good as the Vaadin 7 demo ....)

Vaadin 7 released

Vaadin 7.0.0

It's great to see the Vaadin 7 release finally hit the streets.  I have updated the V7 code to use Vaadin 7.0.0, without any problems.

Demo

I had intended to provide an online demo, and have a server (a VPS to be more specific) all set up and ready to go - but then I ran into a problem with persistence (or to be more accurate, with the VPS set up which is affecting persistence) , so it will have to wait.  Hopefully not for long though.

Persistence

When I started putting the online demo together, I thought it would be interesting to log whether anyone interacts with it.   That meant providing some persistence, so I brought forward my intention to use a database.

I elected to try OrientDB, partly because it provides Object, Graph and Document database options in one.

I will post separately about that experience - but the main obstacle I found was their documentation.  Some of it is quite good, some not so good, but if you Google for it you can very easily end up with different versions of it.  They seem to have moved their code hosting around a bit.

Anyway, if you do want to take a look, do make sure you start the documentation trail here.

It is very early days, and I have only done some trivial tasks with it, but at first sight this database looks simple to use.

Lazy-loading

One thing which did catch me out is the lazy loading of data  ... and it is entirely my fault, as the documentation does say quite clearly that's how it works ... but I fooled myself by looking for values in the debugger;  they were not there of course, because they do not appear until the associated getters are called.

Definitely an RTFM moment that one ....

V7 - Vaadin 7 RC2 Guice and Shiro

Vaadin RC2

I have updated the code to Vaadin 7 release candidate 2, with no issues found.  There was a bug in beta 11 using Chameleon styles, but that is now fixed.

Testing

I've improved the test harness a bit - it pretends now to be a Shiro Web environment, so Shiro generates things like ShiroWebSubject correctly.  This allows a bit more testing within JUnit.

There is a bug in one of the tests - the LoginStatusPanelTest is not configured correctly - but testing is gradually improving overall.

Standard Pages

I have introduced the idea of standard "pages" for things like login, logout and others, to help with some of the Shiro logic.  It is still configurable, so any View could be used to create the "page".

The documentation is still some way behind, and the forum unused, but at least one person contacted me to say they had found it useful.  It is always good to get feedback ...

Vaadin Guice and Shiro - done

Progress

I got there eventually - there is now a working version of the V7 code, which integrates Vaadin 7, Guice 3.0 and Apache Shiro 1.2. 

V7 supports the direct coding of interaction with Shiro, and also the use of Shiro annotations.  If you are not familiar with Shiro then it is worth taking a look.  It greatly simplifies one of those time-consuming development tasks - authentication and authorisation.

Path filtering

The one aspect I have not been able to integrate is the Shiro path filter to apply security according to the URL.  A great idea, and something which could greatly reduce maintenance, but clearly will not work with an AJAX application.

I need to do some more work on that ...

General code state  

I have done quite a bit to tidy up the code, especially for testing.  The test harness is reasonable now, and allows quite a bit of testing of the Vaadin UI, and also incorporates Shiro.

But pretty it is not!  I really have not done justice to Vaadin with the user interface, but just now I am more concerned about function.

Sadly, the documentation  has fallen behind a bit, but I have opened a forum for anyone interested. Comments at the forum, or on this blog would be welcome.