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

In this part I’ll start covering the OsgiWorlds application itself. In the advanced XPages application I added a document wrapper (see part five to refresh yourself). This meant that instead of using the DominoDocument datasource when creating / editing a Key Date, it used a managed bean that was specific for the Key Date form but extended a generic wrapper that Tim Tripcony had created and that I had added to.

If you remember (or have just refreshed yourself) that comprised four Java classes:

  1. uk.co.intec.KeyDateBean which extends
  2. com.timtripcony.AbstractSmartDocumentModel which extends
  3. com.timtripcony.AbstractDocumentMapModel which extends
  4. com.timtripcony.AbstractMapModel

In the OsgiWorlds application this maps to:

  1. uk.co.intec.keyDatesApp.model.KeyDateDocumentWrapper which extends
  2. com.timtripcony.AbstractSmartDocumentModel which extends
  3. com.timtripcony.AbstractDocumentMapModel which extends
  4. com.timtripcony.AbstractMapModel

The base class, com.timtripcony.AbstractMapModel is the same as the XPages version. The others have differences. That’s because I’m now trying to remove the XPages dependencies that were there previously.

AbstractDocumentMapModel

You can view on GitHub the XPages version and the OsgiWorlds version.The first basic difference is the overloaded constructor. XPages passes values in the querystring for ignoreRequestParams and requestParamPrefix, so we needed to handle that in our XPages version. For the OsgiWorlds version, it’s irrelevant, because we are creating our Java objects in Java so there is no point querying URL parameters. The code on the page itself can automatically handle that for us, extracting the documentId and mode from the URL parameters as required.

One of the key differences here is removing a dependency on com.ibm.xsp.model.domino.wrapped.DominoDocument – the backing class behind the DominoDocument datasource – to enable easy loading of fields into the bean, including conversion of Domino classes to Java classes. You should still be able to use com.ibm.xsp.model.domino.wrapped.DominoDocument in an OSGi application, because it’s still has access to the OSGi plugins. And it’s worth bearing in mind that particular class has some very specific functionality for managing rich text content, especially where embedded images or attachments are involved.

Because that dependency is removed, there is now the addition of a typeConversionMap. This determines which Items need converting to which Java classes. It is initialised in the constructor and used in the load() method. Additionally, the load() method also converts a Vector with only one value to the relevant class, so Vector<String> will be converted to String.

The typeConversionMap is not needed when saving because OpenNTF Domino API automatically manages saving Java objects, so the save() method is the same. The only difference in the save(boolean) method is how the notification is generated for the failed save.  In the OsgiWorlds version (because that’s specific for Vaadin anyway) it’s showing a Vaadin notification. For a more generic solution, you could call a method in the application-specific Utils class.

AbstractSmartDocumentModel

Again, you can view on GitHub the XPages version and OsgiWorlds version. There are only minor differences here, wiht the base constructor defaulting to edit mode. The overloaded constructor is also less complicated, because we’re not dealing with documentId or requestParamPrefix. Because the XPages functionality was forcing a full page reload between states, the code did not have to worry about changing mode as completely. However, here setEditMode() also needs to call setReadOnly(!editMode).

KeyDateDocumentWrapper

Again, you can view on GitHub the XPages version and OsgiWorlds version. The only significant difference here is the inclusion of initialiseTypeConversionMap() to identify fields that need converting to a specific Java class.

KeyDateBean

For the OsgiWorlds version, between the KeyDateDocumentWrapper and the web page, there is also a KeyDateBean class. As the Javadoc comments say, this may seem tautologous. But here the bean is intended to expose only those Items that should be editable on the page and to handle any functions to be exposed to the specific page. Here, the underlying Document only contains a handful of fields. But in a scenario where the Document is more complex, this extra level of separation could allow different beans for different “pages” of a wizard or prevent access to fields that should only be set programmatically. It may seem like a lot of typing to create this, but because of the Java editor’s ability to create getters and setters automatically for variables, the bulk of the code is automatically generated.

In the next part, I’ll start to dig into Vaadin a bit by covering the view/edit form itself.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.