From XPages to Web App: Part One – The Application

Home » From XPages to Web App: Part One – The Application

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

The application I’m going to be using for this tutorial can be downloaded from OpenNTF. The KeyDates.nsf application should be installed on a Domino server, preferably at xpagessamples/KeyDates.nsf. If that filepath is used, the future applications will not need changing to automatically pick up the data. If you don’t have an available Domino server, the application can be previewed locally. The second application, the more advanced XPages application will work, but I don’t think the OSGi plugin application will work: I’m not sure Designer alone has the relevant servlet container and, considering there’s no current use case for such a deployment and OSGi applications themselves seem to have some restrictions, it’s not something I’m planning on investigating further.

The application is very simple and works adequately in Notes Client. Here are some screenshots of the “By Date” view, the “Calendar” view and a document.

Key_Dates

Key_Dates_Cal

Key_Dates_Doc

Its Notes Client design is basic, with one Form and a handful of Views, the kind of application created in early Notes releases which still works in R9. Many of you may have or know of applications still in active usage which have little more complexity or sophistication in their UI. It’s the kind of application that “just works” (even though the date field doesn’t even provide a date picker), so gets no love or updating and, to be brutally frank, gives Domino a bad name. But because of its simplicity, it’s actually the perfect kind of solution to give to a new XPages developer.

For web access, I’ve given it the kind of XPages front end that a beginner XPages developer could easily create, but with a few slightly more advanced optimisations. Whether the preferred theme is OneUI or Bootstrap is up to you, but I’ve not used anything more than the out-of-the-box Bootstrap 3.2.0 flat theme available in the more recent versions of the Extension Library. The reason I’ve chosen that is its responsiveness for mobile devices.

KeyDates
KeyDates_ByCustomer
KeyDates_Calendar
KeyDate

The layout uses the Application Layout control. The user experience reproduces the main three views – Key Dates, Calendar and By Customer – that are found in Notes Client. Key Dates and By Customer use the Data View which, in my opinion, should be the preferred basic view control XPages developers should use – I’ve never been a fan of the View Panel because it is so basic. The Calendar view uses the iNotes Calendar control which is the only out-of-the-box option for a calendar view. Unfortunately, the only look and feel available is Domino 8.5.x iNotes look and feel, which is why I don’t have much experience of the components involved. I just followed the documentation in XPages Extension Library to apply it.

There are four aspects that might lift this a little beyond the basic XPages developer. The first is the use of a theme to apply a favicon to all pages. It’s something I first blogged about four and a half years ago. Note Thimo’s correction to my code for the theme and the focus of the blog post, that the favicon needs to be public access and accessible to Anonymous users, if the application will be accessed with authentication.

The second is the Dojo Image Select control used to select the dates on the Calendar XPage. The XPages Extension Library demo application uses individual images, but the Dojo Image Select is the best practice option if image buttons are linked like this. The Extension Library includes icons for the calendar, with different images for selected and deselected. The key is the defaultValue< property of the control and selectedValue property of the individual selectImage child components. The eventHandler partially refreshes the Calendar View control, where the type property sets the layout – one day, two day, work week, week, etc – based on the viewScope variable that the Dojo Image Select is bound to. This means the click event automatically handles displaying the relevant selected/deselected image via client-side JavaScript, just doing a GET request to retrieve any image not previously loaded for the page, and then doing a partial refresh of the calendar to load the contents. You can see that this is happening by looking at the Network tab in Firebug. I am deliberately explicitly breaking down what is happening here, because when we start to move beyond XPages in the future applications, if you want to reproduce XPages data wrappers or user experience steps, you need to be able to break down what’s happening, to identify what steps to reproduce. Similarly, if you see a particular user experience in a non-XPages web application and want to reproduce it, you need to be able to do the same. So, in my opinion, it’s a good habit to get into doing, so it becomes second nature when you need to use it.

The third is the computed link for the summary facet in the ByDate XPages views, as below:

  1. <xp:div xp:key=“summary”>
  2.     <h4>
  3.         <xp:link id=“link1” text=“#{ent.title} (#{ent.customer} – #{ent.contact})”>
  4.         <xp:this.value><![CDATA[/$$OpenDominoDocument.xsp?documentId=#{javascript:ent.getNoteID()}&action=openDocument]]></xp:this.value>
  5.         </xp:link>
  6.     </h4>
  7. </xp:div>

This reproduces the formatting of the Summary column (just launch an XPage that has a summary column in a Data View, look at the HTML and reproduce it – there’s no rocket science involved). This uses Custom Language to calculate the label to allow us to combine the title, the customer and the contact, as well as literal text (open and closing parentheses) to create more complex link text. You could compute the View Column, but that impacts view indexing performance. When the view is displayed, we’re only showing a handful of documents, so the impact is negligible. It means we have to compute the link to open the document, but that again uses Custom Language, this time combining literal text with SSJS to compute the relevant NoteID.

The fourth is the calculation of the corresponding link in the By Customer view, which again uses Custom Language, but this time is a bit more complex:

  1. <xp:div xp:key=“summary”>
  2.     <h4>
  3.         <xp:link id=“link1”>
  4.             <xp:this.value><![CDATA[/$$OpenDominoDocument.xsp?documentId=#{javascript:ent.getNoteID()}&action=openDocument]]></xp:this.value>
  5.         <xp:this.text><![CDATA[#{ent.title} #{javascript:importPackage(uk.co.intec.utils);
  6.             if (view.isRenderingPhase()) AppUtils.convertDate(ent.getColumnValue(“date”));}]]></xp:this.text>
  7.             </xp:link>
  8.         </h4>
  9.     </xp:div>

The SSJS calls a Java method to format the date in a standard format, but only during the Render Response phase, for optimisation. The SSJS in the By Date XPage could also use view.isRenderingPhase() but omits that to demonstrate the difference in code (difference in performance is negligible).

The Key Date document itself uses the Form Layout control. We’re omitting the Department and Staff Involved fields for simplification. I may add that functionality back in the future. But the form does have a Date Picker this time, improving data entry. Note, however, that even though we’re only selecting a date, the documents get stored with Date/Times. This is standard XPages functionality and, as some have noted, the time portion changed in 9.0 to ensure the date remained the same regardless of daylight savings. If you want just the date, you need to do some manipulation during the save process, but it’s worth bearing in mind that then the resulting field will not have a timezone allocated. Obviously with no time, all it can do is assume the same timezone as the server where the code is running.

So that’s our application. Next time we’ll start adding some more complexity to the XPages functionality, advancing it to take in some more advanced XPages concepts.

1 thought on “From XPages to Web App: Part One – The Application”

  1. Pingback: From XPages to Web App Part Sixteen: OSGi JAX-RS REST Access with ODA Revisited

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.

Scroll to Top