Multiple NotesDatabases for Function-specific IBM XPages Application User Interfaces

10/24/2012 by Chris Toohey

I'm working on a project which requires an XPages-based CMS for managing external website content. The UI for this CMS is written using core and extension library controls, and thus uses the OneUIv2.1 theme.

The external website itself uses a completely custom theme that disables all Dojo libraries and instead loads in Twitter Bootstrap and JQuery to deliver a Responsive Web Design user experience.

The problem I immediately ran into was the all-or-nothing (save some major hackery) of Themes and disabling Dojo libraries for XPages. I wanted to use XPages as a roll your own markup delivery solution, and today -- unless I'm missing something, and if I am someone please fill me in -- you cannot disable the Dojo libraries on individual XPages.

Not to mention there is a support issue to consider here. Sure, I can write my own renderers and do all of this slick hacks to get the job done... but someone has to support this in a production environment both today and a few years from now.

Thus, I decided to use two NotesDatabases to serve function-based user interfaces.

Let's take a look at the basic setup below:

Diagram: Multiple NotesDatabases serving function-specific IBM XPages application user interfaces.

Using Remote Data Sources, I could easily create a secondary NotesDatabase configured to an individual function. My External UI, in this context, could use a "blank" theme (doesn't extend an existing theme) and disable all of the Dojo Client Side JavaScript libraries.

An added bonus to this technique is the additional layer of security. As there would be no way to manipulate the NotesData from the publically-accessible External UI NotesDatabase -- as all content management would be handled by the Internal UI NotesDatabase -- I could arguably better secure the external site.

I ran this technique by several other XPages developers to see if I was completely out of my mind when I architected this or if this was - unbeknownst to me - already an established Best Practice. The good news is that everyone at least liked the idea...

Now, something to keep in mind: I'm not recommending this for every XPages-based application. In fact, I'm not even recommending this for Web Browser vs. Mobile Device Browser (ie., client-sensitive) XPages applications. That's an entirely different subject worthy of an individual (if not a series) of posts.

I'm simply pointing this technique out as a option for those of you needing to deliver completely unique user interfaces based on desired function. In my particular case, I had to develop an XPages-based CMS, and I had to develop an XPages-based solution for delivering the desired content (CSS and JavaScript Frameworks, et al).

Your mileage may vary...

So is this a technique that you could use with a project you're working on? Is this something that makes sense to you from a maintenance and support standpoint? Let me know in the comments below.

Share/Like/+1 if you find it useful and want to share.

And expect more posts from this site as well as some major changes in store for celebrating our upcoming 10 year anniversary!