Table of Contents
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
In the last part of the series I covered the wrapper for Key Date documents. That corresponded to a bean behind the XPage in the advanced XPages application. However, it added an additional layer, the KeyDateBean, which exposed only specific Items for the read / edit page. In this implementation it was actually all items, but in a more complex scenario could strip out any Items that would be programmatically set.
In this part I’ll cover that KeyDateBean in greater depth and the integration between that and the KeyDateView, which is the view / edit page. The KeyDateView class in the OsgiWorlds application corresponds to the KeyDate XPage and KeyDateController class. The KeyDateBean and KeyDateDocumentWrapper class in the OsgiWorlds application corresponds to the KeyDateBean class in the XPages application.
Firstly, it’s worth stating that since I’ve dug more into Vaadin and understood a bit more about Vaadin Designer and declarative UIs (there will be more of that in an upcoming blog post on Vaadin’s blog), I would have structured things a bit differently and stripped the KeyDateView back to be more limited to UI. It would correspond more closely to the XPage and the KeyDateBean class would be more of a controller. It would extend the KeyDateView class, instantiate the KeyDateDocumentWrapper and handle functionality behind lookups and events.
The KeyDateView extends
com.vaadin.ui.CssLayout and implements
com.vaadin.navigator.View. This means it is a sub-page within the overall Vaadin single page application (so the URL will be “…/#!KeyDate”, the VIEW_NAME), using the CssLayout layout. Because it implements
View, it has an
enter() method, which is what is triggered every time this page is opened. Each time we will have a different document, so this is where we retrieve the document ID from the querystring, if there is one, load the KeyDateDocumentWrapper and instantiate the KeyDateBean based upon it. Finally we load the UI.
The first part of the
loadContent() method, after setting some sizing on the FormLayout, just loads the fields in the KeyDateBean into a BeanFieldGroup. This allows easy access to all named properties of a bean. It seems to be effectively a datasource wrapper to allow binding between form fields and the backend bean. For each field we call
buildAndBind() passing in the label, the KeyDateBean property and the field type. Other methods, like
setRequiredError should be self-explanatory. With the date field, Vaadin allows us to restrict the start and end date ranges. The Customer combo box has a variety of methods set, again they should appear self-explanatory, but the key elements are
setImmediate(true) and the
Property.ValueChangeListener. By setting
immediate to true, we’re ensuring the
valueChange event isn’t prevented from firing by invalid fields on the page. What that event does is set the options for the Contact combo box by retrieving the contacts for this Customer. The Contacts combo box is also pretty self-explanatory.
It’s worth considering, when we’re handling components, that in XPages all the properties available in the All Properties panes are backed by getters and setters, so
value will be programmatically handled by
rendered will be programmatically handled by
setRendered(boolean). If you look at the Java files for any XPage or Custom Control in the Local folder in Package Explorer, you’ll see this code, somewhat complicated because of the switch statement for creating each component. But comparing the XPpages code and Vaadin code for components and even the component names, it’s actually very similar.
The buttons appear at the bottom and visibility is managed based on whether the KeyDateDocumentWrapper is in edit mode or not. The Edit and Save buttons are given a primary style, so they stand out more to the users, a UX best practice covered in one of Vaadin’s webinars. They effectively just switch the mode of the KeyDateDocumentWrapper, readOnly property of the BeanFieldGroup and change visbility of the buttons. The save obviously also saves the KeyDateDocumentWrapper. The Cancel button navigates back to the view the user came from. It seems complex, but when you step back and think through the individual processes that need to take place, it’s pretty straightforward.
Finally, and crucially, we need to remember to add the components to the Form Layout and add the Form Layout to the KeyDateView. This is the most common mistake I’ve made in Vaadin development!
In the next part we’ll dig into the rest of the structure of the application and see how the form and views fit into it all.