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.