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 the last part I introduced the Key Dates application that is being used for this blog series, both its Notes Client user interface and a basic XPages interface. For the next part of the blog series, I’ll be extending a copy of that design. The look and feel of the application will not change at all. What will change is
- the data is no longer being stored and retrieved from the NSF that holds the web application design. This is an approach that will be familiar to those who have tried the Bluemix XPages offering. But it’s been possible for XPages on premises since its inception and one that I have used, on occasion, since the very earliest days.
- the DominoDocument datasource will be replaced with a wrapper. The code I’ll be using here extends Tim Tripcony’s SmartDocumentModel from NotesIn9 episodes, because it also allows us to add extended functionality. In this case it’s being created as a managed bean, but that’s just a personal choice to make it simpler for those moving from simple to advanced XPages. It is also a big step to removing the dependency on XPages. When we get to the OSGi application, you will see there are only a small number of changes required.
- the Key Date document XPage will be backed by a pseudo-controller class. That will handle access to the document wrapper as well as management of some UI elements like typeahead for the customer and contact. The way I’m mapping the XPage to the pseudo-controller class is different from the way Jesse Gallagher’s framework handles it and Jesse’s method is the one I would recommend. The way I’ve done it here is to simplify the step for those who have not used controllers and to demystify the concept.
- the application will depend on OpenNTF Domino API. That is because interacting with the fields from Java has a number of quirks, as shown by the extra code Tim needed in his wrapper to write to and retrieve values from Notes Items.
The views are still handled with dominoView datasources. That is deliberate, to reinforce that this “new” method of a document wrapper is not at all new. It’s effectively the same concept as the dominoDocument datasource or the dominoView datasource: all are just wrappers around the backend Domino objects (Views or Documents) which allow the content to be stored in memory between requests to the page and act as a gatekeeper between the web page and the underlying database. All have their own functionality for creating the object and saving the object. Beyond that they’re all the same, they’re all just instances of a Java class. Because even though they’re data sources, dominoView and dominoDocument are really Java classes with properties and methods.
In the next part I’ll start going into more depth on the differences.
