Vaadin, Guice and Shiro

Formalising

Once I made some progress integrating Apache Shiro, I realised that what started as an experimental integration of Vaadin and Guice is becoming a rather more substantial project - something for me to use as a base for future applications, and maybe something others could use too.

So I have started formalising things a bit more.  I've started some documentation, partly to clarify my thoughts, but also to share with anyone who is interested.

The code is still in the same place, but I will start using a proper branching model so that the master branch becomes more stable  - until now I haven't been concerned about that.

Shiro

The integration is extremely rough at the moment, but it does demonstrate a login (hard-coded for now).   I think I will go for the URL based model provided by Shiro, provided I can get that to work with Vaadin.

Refactoring

I've done quite a bit of moving code around to try and separate what should be the base V7 reference, and the demo code

Vaadin 7 beta 11

Changes from beta 10

I noticed a couple of small changes from beta 10:

VaadinRequest parameters

The parameter names have changed.  I was using "loc" to return the location from Page, using a mocked VaadinRequest.  The parameter name has changed to "v-loc".  I notice the width and height parameters are now pre-fixed with "v-" as well.

Chameleon Button style

I was using the "big" style for buttons, but this no longer works, and neither does "small".   I've changed to using "tall" for now, and posted a question on the Vaadin forum

A working model

Well, I do have a working model now, and the code does most of what I wanted to do.  The disappointment was the amount of classes I had to override in order to get this working - caused mainly by the native Vaadin Navigator being a concrete class.

I've suggested to the Vaadin team that Navigator should be an interface to make things more flexible, and hopefully that will be taken up.

I also noted the recent post about CDI on the Vaadin forum - I probably should make sure that my effort aligns to CDI even if I don't use CDI directly.

Vaadin 7 Navigator with Guice

Following my earlier work, I started out thinking that I only had to make a few changes around the   Vaadin 7 Navigator to make it Guice friendly.

It seems that is not the case!

The standard Vaadin 7 Navigator class is very closely coupled to a number of other classes, and I have ended up developing a parallel navigation scheme.  It was not what I intended, but it will allow me to make more use of Guice functionality - which in most ways Vaadin is very well suited to, as it is a component based framework.

So - work is in progress.

Vaadin 7 navigation and parameters

The good bit

URI parameter handling

Adding handling for URI parameters to the sample app was straightforward, the new Vaadin 7 architecture makes it easy. 

Error View

Putting in an error view, to deal with invalid URIs was equally simple.

Appearances

I have tidied up the appearance of the app - it won't win any design prizes but it does look a bit better.  More importantly it demonstrates more clearly some of the basics I was trying to establish.

The Not So Good Bit

Concrete classes

The use of some concrete classes (as opposed to interfaces) in the navigation scheme is getting in the way of some options I would like to use with Guice.  The Navigator itself is a concrete class, with constructor parameters, and although it is possible to get round this it would have been much easier if there had been a Navigator interface, and say, a DefaultNavigator implementation.   

Vaadin 7 and Guice custom scope

In a previous project using Vaadin 6 and Navigator7, we found it helpful to have a Guice scope which matched a "browser tab".  This was for things like message bars, toolbars and breadcrumbs and made good use of the dependency injection paradigm.

In Vaadin 7, the nearest scope to this would be UI - so I  have added a UIScope to the sample app.  It seems to work, but still needs proper testing, so it resides in a separate branch for now.

One of the problems with this is that when a new UI is created it will almost certainly require injection of UIScope components - but the UI itself has not yet been constructed so cannot be used as a scope reference.

To get round this I use a surrogate key (an instance of UIKey), and hold it in CurrentInstance, a ThreadLocal store provided by Vaadin 7.

Vaadin 7 Navigation and Parameters

Parameter handling

The code in the sample app is still  ugly in places, but is starting to take shape.  

URI Decoder

I have used a more strict interpretation of the UriFragment than Vaadin does by default, and made it a requirement that the URI structure is of the form:

http://example.com/domain#!finance/report/risk/id=1223/year=2012

where:

 

finance/report/risk/

is a "virtual page path" and is represented by a View implementation, and everything after it is paired parameters.

This is not as flexible as the standard Vaadin approach - but I just prefer it.  It could easily be changed by using a different implementation of URIDecoder.

Site Map 

The approach I have taken with the Guice based View provider means that I can put all the mapping of View name to View class in one place - in effect, a site map.  At the moment it is part of the provider, but needs to be separated out.