From XPages to Web App Part Ten: Vaadin

Table of Contents
Introduction
Part One – The Application
Part Two – XPages Advanced 1
Part Three: XPages Advanced Database Separation
Part Four: XPages Advanced Document Wrapper
Part Five: XPages Advanced MVC Controller
Part Six: Use of OpenNTF Domino API
Part Seven: OSGi Application Development Introduction
Part Eight: OSGi JAX-RS REST Access with ODA
Part Nine: OsgiWorlds
Part Ten: Vaadin
Part Eleven: OsgiWorlds Document Wrapper
Part Twelve: Key Date Page

Part Thirteen: Application Structure
Part Fourteen: Calendar View
Glossary

When it comes to web application development, much of the focus is on which JavaScript web framework to choose. Anyone who has read my blog for any period of time will be aware that I’m not a JavaScript expert and has not been a language I’ve favoured, mainly because of the editors available to us as Domino developers. I’m also very conscious of how quickly the JavaScript landscape changes. When I started with XPages in 2009 I had already started stepping beyond basic Domino web development and had been using Dojo for a little while. But for a couple of years now Dojo has been lees in vogue than jQuery. Now most web applications are built on a framework based on jQuery, as far as I can tell, and there are a host of them. So not knowing which one to choose means picking one, learning it, trying it and – potentially – repeating that if the framework chosen doesn’t work. Add in the situations already encountered in Bootstrap and AngularJS where there is a radical change between versions which seem to mean redeveloping rather than upgrading, and choosing a JavaScript framework seems rather unappealing to me.

In parts seven and eight I talked about why I feel Java is the best practice choice for REST services for client-side JavaScript web applications: LotusScript does not have in-built or open sourced libraries for easily handling HTTP response classes and JSON objects; SSJS XAgents are not designed for object oriented programming, which is required for HTTP response objects and JSON responses; DAS does not force content validation and doesn’t really attempt to allow for workflow processing; Extension Library REST components are also designed principally for read access and again don’t handle workflow processing. So all this really leaves Java.

If you have a large team, it’s more feasible to have the flexibility of Java experts writing the back-end and JavaScript experts writing the front-end. But that’s not usually the case for many Domino development teams. The companies I’ve worked for or dealt with usually have a team for Domino applications of less than five people, so splitting back-end and front-end is not very feasible.

So the logical step for me is that if I need Java for the back-end and have already built up Java skills within XPages, I’d prefer to use Java for the whole of my web application. And considering the Java landscape doesn’t change direction as quickly, that also makes me feel more comfortable.

There are a few Java frameworks out there and probably the one most XPages developers will be most aware of (even if they don’t realise it) is JSF, on which XPages is based. And in a recent DZone survey, it topped the list of Java web frameworks. The one I’ve chosen, though, is Vaadin.

I first came across Vaadin a couple of years ago when I and only a handful of others went to a session by Mark Myers about using Vaadin with and without Domino. I next came across it as the chosen Java web framework for a conference application on CrossWorlds I helped out with at the beginning of this year. The high quality of documentation, the experience of using it to develop something that wasn’t just a “Hello World” application, the ease of implementing demos, the number of addons available, the quality of forum responses, and the general ease of transition from XPages have made it the framework of choice for me. It’s gained greater prominence through this year by virtue of being the first third-party framework available on Bluemix, as well as having had two Bluemix competitions for Vaadin this year. Indeed the pro tools include a WYSIWYG / XML editor which, when the page is saved, gets compiled down to Java classes. Hmm, that sounds familiar!

The key documentation is the Book of Vaadin which I’ve always found very comprehensive as a reference guide. But there is also training, webinars, support options, certification (note: this is much more challenging that IBM certifications because every question is multi-choice but no guidance of how many answers are required!). There is also an online list of examples. There is also a separate sampler application (with a Vaadin 6 version as well that’s still a useful resource). There are also a large number of addons available. When it comes to questions, there are many on StackOverflow but Vaadin’s own forum answers most questions (so I usually Google and let it lead me to the right place).

Vaadin itself is built on GWT and HTML5, but also allows embedding other Java frameworks like Swing within it. As well as the server-side development model, Vaadin also provides a client-wide development model, allowing client-side widgets to be developed in Java or client-side GWT applications to be built. But because it’s a server-side framework, it has the stateful benefits XPages developers are familiar with. In terms of the Java code that’s written, if you look at code in the Local folder in Package Explorer – the Java code that backs your XPages and Custom Controls – the Vaadin code in the applications will be quite similar. That Local folder may seem confusing for a start, but cross-referencing with the XPage helps break it down. The key for both XPages and Vaadin is that the components are Java objects that are then added to a Panel or the XPage itself. (Forgetting to add a component to a panel is a big gotcha in my Vaadin experience!)

In the next part I’ll start digging into the OsgiWorlds application itself.