Coaxing Enums Into XPage Combo Boxes

  • May 28, 2014

I've been reworking Forms 'n' Views over the last couple days to use it as a development companion for the OpenNTF Design API, and one of the minor hurdles I ran across was presenting a getter/setter pair that expects a Java Enum to an XPages control (a combo box in this case, but it would be the same with other similar controls). I had assumed at first that it would simply not work - that the runtime would entirely balk at the conversion. However, it turned out that XPages does half the job for you: for displaying existing values, it will properly coax between the string form and the Enum constant. However, it breaks when actually going to set the value.

This whetted my appetite enough that I decided to try to see if I could write a small converter to finish the job in a properly generic way, and it turns out I could. To cut to the chase, I wrote this class:

package converter;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.el.ValueBinding;

public class EnumBindingConverter implements Converter {

	public Object getAsObject(final FacesContext facesContext, final UIComponent component, final String value) {
		ValueBinding binding = component.getValueBinding("value");
		Class<? extends Enum> enumType = binding.getType(facesContext);

		return Enum.valueOf(enumType, value);

	public String getAsString(final FacesContext facesContext, final UIComponent component, final Object value) {
		return String.valueOf(value);


The getAsString method is your standard "I don't care about this" near-passthrough, but the getAsObject portion does the work necessary. Because I'm binding to a Java bean with getters/setters expecting the appropriate Enum type (this would presumably also work with a DataObject with a thoroughly-implemented getType method), the ValueBinding class is able to look up and provide back the expected Enum class. I then use the standard Enum.valueOf method to let Java do the work of actually finding the appropriate Enum constant.

Using this, I'm able to write a control like this:

<xp:comboBox value="#{columnNode.sortOrder}">
	<xp:this.converter><xp:converter converterId="enumBindingConverter"/></xp:this.converter>
	<xp:selectItem itemLabel="None" itemValue="${}" />
	<xp:selectItem itemLabel="Ascending" itemValue="${}"/>
	<xp:selectItem itemLabel="Descending" itemValue="${}"/>

And it works! That allows you to bind to a getter/setter pair that expects an Enum without having to write in a shim to convert it to a String value beyond the generic converter.

You probably noticed the same thing I did, though: that's ugly as sin. Not only that, but it's a lot of redundant code when what you usually want to do is provide a selection of all available constants for the given Enum. To save myself a bit of future hassle and prettify my code a bit (at the expense of UI, but who cares about that? (I kid)). I wrote this DataObject bean to accept an Enum class name and return a list suitable for use in a control:

package bean;

import java.util.*;

import javax.faces.context.FacesContext;
import javax.faces.model.SelectItem;

import org.openntf.domino.utils.Strings;


import frostillicus.bean.*;

public class EnumSelectItems implements Serializable, DataObject {
	private static final long serialVersionUID = 1L;

	public Class<?> getType(final Object key) {
		return List.class;

	public List<SelectItem> getValue(final Object key) {
		if(key == null) {
			throw new NullPointerException("key cannot be null.");

		String className = String.valueOf(key);

		try {
			Class<? extends Enum> enumClass = (Class<? extends Enum>)FacesContext.getCurrentInstance().getContextClassLoader().loadClass(className);

			Enum[] vals = enumClass.getEnumConstants();
			List<SelectItem> result = new ArrayList<SelectItem>(vals.length);
			for(Enum val : vals) {
				SelectItem item = new SelectItem();

			return result;
		} catch(Throwable t) {
			throw new RuntimeException(t);

	public boolean isReadOnly(final Object key) {
		return true;

	public void setValue(final Object key, final Object value) { }

It uses the @ManagedBean implementation that I cobbled together a while back, but you could just as easily use the normal faces-config route. The way you use this is to pass in the class name of the Enum you want in a selectItems component:

<xp:comboBox value="#{columnNode.sortOrder}" onchange="fnv_mark_dirty('#{id:viewPane}')">
	<xp:this.converter><xp:converter converterId="enumBindingConverter"/></xp:this.converter>
	<xp:selectItems value="${enumItems['$SortOrder']}"/>

Though it only saves a few line in this case, it'd pay off more with larger Enums. It has the down side of being pretty naive about its conversions: it just does a basic first-character proper-casing of the Enum constant name, but there's no reason you couldn't add better human-friendly-ifying to it.

I'm not sure if I'll be able to satisfy all of my Java preferences when it comes to multi-value Enums, though. Java's generic type erasure means that runtime code wouldn't have a way to inspect the getters/setters to figure out the appropriate Enum type. Perhaps I can inspect the select items attached to the control to find the appropriate class.

Code for Tim: LESS CSS for XPages

  • May 25, 2014

When OpenNTF announced the "Code for Tim" initiative, I browsed Tim's GitHub repository list and one stuck out to me: the "xspless" stub repository for adding LESS CSS support to XPages. I'd latently wished for this sort of feature for a while, but hadn't yet set out down the path. It seems Tim had had the same desire, and had taken at least one more step than me.

I've decided to try my hand at making this desire a reality, and it's borne some fruit so far. I've created a fork of his project to house my attempts:

So far, I've made functional drafts of two tacks:

  • A servlet plugin for Domino, in the "org.openntf.xsp.less" and ".feature" projects. This servlet is available at "/xspless" within each database (behavior outside of a database is not handled) and it processes the named file (can be a Stylesheet resource, File Resource, or file in WebContent) just-in-time and delivers the result as normal CSS
  • A builder plugin for Designer, in the "org.openntf.xsp.less.builder" and ".feature" projects. This builder adds a new Eclipse Nature to Designer (activated per-project by right-clicking the app and choosing "Add/Remove LESS CSS Nature") that compiles Stylesheet resources named in the form of "foo.less.css" (Designer automatically appends the ".css") and other File or WebContent resources named in the form of "foo.less" and stores the compiled results in the NSF

My ideal goal would be the ability to write .less files in Designer without any plugins and have the server treat them as normal CSS files with pre-processing, including them in resource-aggregation chains. Since I don't currently know how to have files processed on the fly and also included in aggregation, I created the two routes, with the latter being the likely-preferred route. Though it requires installing a plugin on each developer's system, it has the distinct advantage of the resultant files working perfectly with the normal resource aggregation pipleline of the server.

In their current state, these plugins seem to do their job. If I find out a way to hook into the resource chain on the server transparently, I'll look to improve the server plugin, but for now the Designer plugin seems promising. I plan to give a shot to using it for normal development; it will likely be a refreshing change of pace to be able to use LESS to write cleaner CSS. After a bit of testing, I'll likely create a project on OpenNTF.

Be a Better Programmer, Part 2

  • May 22, 2014

For this week's installment, I'd like to cover a more abstract topic than last time:

Develop a Philosophy of Programming

By this grandiose title I don't mean that your outlook on programming has to be an answer to life, the universe, and everything (though tell me if it is), but more that it's useful to know why you do what you do. Why are you a programmer? I'm assuming it's not because of a particular love for "delivering" "enterprise" "workflow" "solutions".

In my case, it's because I find the act of programming to immensely joyful (even when it's a pain). The best times are when I'm working on something and my brain is just saying "This is awesome" - whether the actual end product remains awesome is largely immaterial; it's more the act of creating it. Good thing, too, since another part of the joy is figuring out why the stuff I did before is awful in light of a new idea I've had.

The most influential thing I've read on the notion of programmer identity is Paul Graham's Hackers and Painters. His numerous other essays are also generally worth a read, but that one has stuck with me. The crucial aspect is that he aligns programmers' personalities with those of artists (over-reduced to "painters") rather than the scientists and mathematicians that Computer Science grew up with. Over the years, I've spent a lot of time thinking about where programming fits in the pantheon of professions, and I think the essay is mostly right. Certainly, programmers share a lot of traits with mathematicians (pedantry, for one), but otherwise the math/science basis of programming is something of an implementation detail. The real beating heart of programming is the joy of creating - or even just the joy of tinkering and trying, of discovering the contours of the medium.

Deciding on your philosophy of programming, whether it matches mine or takes a different path, isn't something that directly assists your day-to-day work, but I think it informs the whole. Having this sense of identity gives me a solid feeling of why I'm doing what I'm doing and an intrinsic motivation to do it properly. It helps push me to elevate my code past "the first thing that works" and into an intentionally-crafted product. Far from being a flighty academic exercise, thinking this sort of thing through has bolstered my consistent drive to improve.

For-fun Project: NSF StateManager

  • May 20, 2014

Earlier this year, I created a StateManager for XPages using Couchbase as a back end. Mostly, this was just to give myself an excuse to mess around with XPages internals and Couchbase. But even still, it had an interesting characteristic: by storing the state of an XPage between requests in a location available to multiple servers, the XPages became cluster-friendly - you could load an XPage on one server and make later requests to another (though it would take further work to handle other scopes).

I was prompted today by a discussion on the possibilities of this sort of thing to go back to that code and adapt it to storing the data in Domino. The initial work was pretty straightforward: using the baked-in Database#getDocumentByKey and MIMEBean capabilities of the OpenNTF Domino API, the same key-value concepts I used for the Couchbase version transferred neatly. At that point, I had the same cool cluster/failover-friendliness as before, but now using NSF for storage.

But then Nathan egged me on further: he pointed out that there's no reason to stop at just storing the last state; I could store every revision. Suddenly, a world of possibilities are open: an audit trail of page state, the ability to view this trail from externally (tied to context information like DB path and username), and the ability for the user to step back through the tree. I set to implementing that last one immediately:


If you'll forgive the off-by-one problem in the history display and the sparse layout, you can see it in action: the user is able to revert the view to a previous state, with the entire viewScope coming along for the ride. Additionally, I realized I could store this traversal history as a tree (I told you they come in handy) to visualize the act of a user stepping back in state and creating a new branch from there:

Domino State Viewer

Currently, this is largely of nerdy-interest concern, but there are a lot of ways this could be built up into a real useful tool. Users could have a built-in "undo" tool (assuming you're undoing actions without external side effects), an admin could see the specific actions taken and buttons clicked by a user using a page, the app could peer into the state of all users using a given page to present a collaborative UI, and so forth.

I created a "Miscellany" project on GitHub intended to house pie-in-the-sky one-offs/test projects like this, and so the curious can find the code there:

The DSAPI Login Filter I Wrote Years Ago

  • May 19, 2014

In one of the conversations I had at the meetup yesterday, I was reminded of the DSAPI filter I use on my server for authentication, and remembered I'd yet to properly blog about it.

Years ago, I had a problem: I was setting up an XPages-based forum site for my WoW guild, and I wanted sticky logins. Since my guildies are actual humans and not corporate drones subject to the whims of an IT department, I couldn't expect them to put up with having to log in every browser session, nor did I want to deal with SSO tokens expiring seemingly randomly during normal use. My first swing at the problem was to grossly extend the length of Domino's web sessions and tweak the auth cookie on the server to make it persist between browser launches, but that still broke whenever I restarted the server or HTTP task.

What I wanted instead was a way to have the user authenticate in a way that was separate from the normal Domino login routine, but would still grant them normal rights as a Domino user, reader fields and all. Because my sense of work:reward ratios is terribly flawed, I wrote a DSAPI filter in C. Now, I hadn't written a line of C since a course or two in college, and I hadn't the foggiest notion of how the Domino C API works (for the record, I consider myself as now having exactly the foggiest notion), and the result is a mess. However, it contains the kernel of some interesting concepts. So here's the file, warts, unncessary comments, probable memory leaks or buffer overflows, and all:


The gist of the way my login works is that, when you log in to the forum app, a bit of code (in an SSJS library, because I was young and foolish) finds the appropriate ShortName, does a basic XOR semi-encryption on it, BASE64s the result, and stores it in a cookie. The job of this DSAPI filter, then, is to look for the presence of the cookie, de-BASE64 it, re-XOR it back to shape, and pass the username back to Domino.

Now, the thing that's interesting to me is that, because you've hooked directly into Domino's authentication stack, the server trusts the filter's result implicitly. It doesn't have to check the password and - interestingly - the user doesn't actually have to exist in any known Directory. So you can make up any old thing:

CN=James T. Kirk/OU=Starfleet/O=UFP

Though I do not, in fact, maintain a Directory for the Federation, Domino is perfectly happy to take this name and run with it, generating a full-fledged names list:

Names List: CN=James T. Kirk/OU=Starfleet/O=UFP, *, */OU=Starfleet/O=UFP, */O=UFP

It gets better: you can use any of these names, globs included, in Directory groups or DB-level ACLs and they're included transparently. So I set up a couple groups in the main Directory containing either the full username or "*/OU=Starfleet/O=UFP" and also granted "*/O=UFP" Editor access and an Admin role in the DB itself. Lo and behold:

Names List: CN=James T. Kirk/OU=Starfleet/O=UFP, *, */OU=Starfleet/O=UFP, */O=UFP, Starfleet Captains, Guys Who Aren't As Good As Picard, [Admin]
Access Level: Editor

Now we're somewhere interesting! Though I didn't use it for this purpose (all my users actually exist in a normal Directory), you could presumably use this to do per-app user pools while still maintaining the benefits of Domino-level authentication (reader fields, ACLs, user tracking). With a lot of coordination, you could write your C filter to look for appropriate views in the database matching the incoming HTTP request and only pass through the username when the cookie credentials match a document in the requested app. Really, only the requirements of high performance and the relentless difficulty of writing non-server-crashing C stand in between you and doing some really clever things with web authentication.


Be a Better Programmer, Part 1

  • May 15, 2014

For over a year now, I've had notes on this blog-post series sitting on my desktop, staring at me and asking why I haven't actually started it. Well, I'm going to start it now.

The title and core concept are stolen from the illustrious Day[9], though I expect any mentions of video games will be incidental at best. What I want to do is encourage everyone, myself included, to be a better programmer, and I aim to do this by sharing overall concepts and strategies that I have found to help me. Some of these (like the quick one today) will be about generic concepts with more-or-less direct applicability to daily programming, while others will fall more to the sides of either "here's a neat trick" or more of an overall outlook on life and the profession.

To start off easily, I'm going to bang a drum I've banged before:

Data Structures

In Java, the most applicable form of knowing about data structures is the Collections framework, but they pay dividends even if you never write a line of Java (or work with a Java framework like XPages) in your life. I learned about data structures in college, but I recognize that "having been a CS major" isn't a viable option for non-time-travelers. The Wikipedia article does a decent job going over the basics of the types, though actually following the links to them runs the high risk of stumbling into the mathematical foundations and arcane pseudocode, which are of interest primarily to CS professors.

The good news is that I forgot the vast majority of the actual details of the structures yet still derive tremendous benefit. The best example of that is when it comes to Trees. In my mind, Trees have a couple primary points of note:

  • They consist of a root node that has zero or more children, each of which also has zero or more children.
  • There are two main categories of Trees to know about: binary and non-binary. What this just means is whether the count of children is limited to two or not. The primary purpose of this limit is for searching: left is "less than" and right is "greater than".
  • Binary trees are great for keeping and traversing sorted sets of data (thus Java's TreeSet), while non-binary trees are great for representing hierarchies (such as an XPage or an org chart).
  • If you're dealing with trees, you're probably going to do some recursion.

Once you know a bit about Trees, they start popping up everywhere: the ExtLib is rife with "leafNodes" and the like, JSON and XML data can be safely thought of as a Tree, and database indexes (like Views) fit the bill as well.

Unless you're actually implementing a low-level library, you don't really need to know more than the broad strokes. I learned tons of stuff about representing Trees as an array, algorithms for traversing them, and various specialized types (like Red-black Trees), but I've forgotten basically all of that.

I've found having a working knowledge of the various types to be a tremendous benefit in visualizing the structure of a program, in figuring out why something works the way it does, and in coming up with good solutions to a variety of problems. I recommend finding some tutorials online (maybe this guy, though I haven't watched them) and familiarizing yourself with the basics. You will likely find that it will be a stepping stone to greater understanding of basically everything you do as a programmer.

So it goes.

  • May 12, 2014

Having only briefly met Tim Tripcony in person and lacking the writing skill for the task, I feel like it's not entirely proper for me to comment on his death, but I'm doing to do so anyway.

Years ago, when I was finding out about the Lotus community and starting my journey learning XPages, Tim immediately stood out as one of The People to pay attention to. His knowledge of the platform and willingness to share made his blog an excellent resource, but it was more than that. In a way that is extraordinarily rare in the world, Tim wrote code that wasn't just good or useful, but Right. Just looking at the way he approached and solved a problem, you could tell immediately that it was correct, that it was the product of a mind filled not just with knowledge and trivia, but with a desire to come up with the best, most beautiful solution.

That's a skill and a way of going about programming that I strive to reach, and I was glad to ride Tim's coattails in that direction when I could. When I read a blog post of his, I knew immediately it was advice to take to heart. When I saw that his approach differed from mine, I knew that mine was wrong. He was the type of programmer I want to be.

And though I didn't know him very well personally, it was clear that his joy in sharing and sense of humor shone through. Talking to him and reading his work, you could tell he relished the opportunity to engage with others and mutually improve. His generosity and evenhandedness are further traits I aspire to.

I admired him immensely, and I have a hollow feeling in my gut knowing that I won't have an opportunity to know him better.

Book Review: Mastering XPages, Second Edition

  • May 11, 2014

For a review of Mastering Xpages, I could copy almost wholesale the introduction from my review of XPages Extension Library: the low count of XPages books makes each one an essential purchase. As before, fortunately the book rises above that obligatory baseline and is absolutely worth your time. That's the upshot of this review: if you're a Domino programmer, buy and read this book.


One of the first things you notice about the book is its size, clocking in at over a thousand pages. This is a function of the complexity of the platform and the breadth of its intended audiences. Due to its role as "the" XPages book, it contains content meant for people ranging from legacy Domino devs, experienced XPages devs, people entirely new to the platform, and JSF programmers new to Domino.

Fortunately, the structure of the book makes this manageable. Particularly once you get to Part IV, it is essentially a collection of self-contained topic references. Though it would be a good idea to read through the entire thing, there are large sections that you can hold off on until you have a need, such as XPiNC, mobile development, and internationalization.

Changes Since Last Time

The original edition of Mastering XPages was written for Dominp 8.5.2, before the Extension Library and before knowledge of real XPages development had really started infusing the community outside of a couple teams. The additions since the previous version focus largely on the "mainstreaming" of several Extension Library controls and concepts (without going into the exhaustive coverage of the Extension Library book proper), further coverage of Java's role in XPages development, and sort of a "best of" of IBM's releases in the interim: the XPages Toolbox, improved debugging, Tony McGuckin's Masterclass series on performance and scalability, and even the Rich Text Editor Evolution control. These provide a much more well-rounded view of what modern XPages development actually consists of, beyond the comparatively-primitive (and buggy) options in a stock 8.5.2 installation.


I was very pleased to see heavy coverage of Java development in XPages, starting off early (and possibly intimidatingly) with a chapter on XPages' JSF roots and the Java classes/interfaces that make up its true form. To suit the various target audiences, this coverage runs the gamut from creating managed beans, to logging/performance tracking, to creating controls and renderers whole-cloth.

However, I'll admit that I wished there was another level represented: writing your business logic in Java, probably via managed beans. The IBM-advocated way is to use SSJS for business logic and use Java when you have a particularly JSF-related need, though, so the lack of this topic is a result of that.

Lack of Opinion

My primary quibble with the book is basically the same as my problem with the platform as a whole: it's not opinionated. XPages, as a platform, is massive, and trying to understand every moving part is likely impractical for anyone whose job isn't focused on either writing or manipulating the entire thing. As a Java-based framework, it carries enterprise Java's tendency for massive class hierarchies, factories, layers of configuration, and several types of indirection. As a system grafted on top of Domino, it bears the scars of merging with a platform and development ideology often at odds with JSF's origins. And as a modern web framework, it requires involvement in the dizzying array of web technologies and idioms.

The result of this is that it's often largely unclear what the best way to accomplish a task is. It's outside of the book's bailiwick to establish this One True Way (to my knowledge, no such Way exists for XPages), but the state of affairs leads to some potentially-confusing results.

On a micro scale, there's the example of resources in themes. Themes provide two syntaxes for including JavaScript and CSS files: the "legacy" way (<resource> elements) and the good way (the <resources> element and its XSP-alike children). The book mentions both, and even explicitly describes the latter as the one to use, but it, like Designer help and the default comments in a new theme file, still uses the older style for the actual examples. It would be better to mention the existence of the old style for in case you run into it, but otherwise ignore its existence.

On a macro scale, what the book lacks is a guide to building a full application. The book is rife with downlodable examples, and those are helpful, but I think it could be all the better to demonstrate building one of the canonical "tutorial"-type apps, such as a to-do list or store. An example of using each main topic in the same from-scratch app (CRUD basics with Domino documents, building a layout using Application Layout, mobile-enablement with the mobile controls, adding internationalization, and finally performance monitoring and tweaking) could provide a valuable guide to how to build a solid, performant XPages app. The use of the discussion app does a bit of this, but most of that app is already written, and it's not a consistent thread through the book.


Overall, gripes aside, my original opinion remains: this book is a valuable resource for any Domino developer. Its value goes beyond the initial reading as well, as it will be a powerful go-to reference tome for major subjects (especially if you get the ebook version and can just search). For my part, I expect the chapter on building components to be particularly useful as I delve further into the topic. If you haven't purchased this yet (or coaxed your company into purchasing it for you), remedy that immediately.

Pretty URLs: A Step in the Right Direction

  • May 9, 2014

A long time ago, I mused a bit about the URL problem in XPages. The core problem then, as it is today, was that XPage URLs are ugly as sin. Domino URLs were never pretty, but XPages took them back a few steps. Just look at this normal-case monstrosity:

Barely any part of that has anything to do with the task at hand! Some parts - like the folder path and NSF name - are only tangentially related, while others - like "action=openDocument" are little more than an implementation detail. The inhuman UNID gets a half-pass by virtue of its value as a cluster-friendly identifier, but it would be better as a human-readable unique key.

What you'd REALLY want would be a WordPress-and-others-style URL like this:

Now THAT'S a functional URL: every part of it is both explicable to humans and useful to computers as a unique identifier. More importantly, it establishes a clear hierarchy: any part of it can be traversed to get a conceptually-useful URL (assuming your app implements it). "/blog/2014/5" has a clear meaning: "give me all entries in the 'blog' app for May 2014".

Domino provides little assistance in getting to this point. There are web rules, yes, but that leaves two crucial problems: 1) your app needs to know about these rules, so it generates nice URLs and not eldrtich horrors and 2) you need to set up a server-level config for every web site + function combination. You can't just say "send all requests for /blog to so-and-so app" and then have that app handle everything past that. This is something of an impassable brick wall: Domino's original URL router is still in full effect even in the most modern of apps, and so the XPages side of an app doesn't even hear about a URL request unless it's in the form of "app.nsf/somepage.xsp" or "app.nsf/xsp/whatever" (and the latter form is something of a Wild West full of resource providers, servlets, and who-knows-what else).

But there's a twinkle of hope: because you specify all URLs in an XPage as relative to the app, that means that there's a post-processing service in there that translates a URL like "/foo.xsp" into a full server-relative URL like "/somedir/app.nsf/foo.xsp". That service has a name: ViewHandler. ViewHandlers have been one of my preferred tools in XPages ever since I discovered their utility in instantiating my soon-to-be-renamed "controller" classes. In addition to their role in creating pages and potentially intercepting page requests, ViewHandlers serve a crucial role: providing resource and action URLs. In XPages/JSF parlance, an "action" URL is what shows up in the form tag on the HTML result, while a "resource" URL is, well, basically everything else. When a control on an XPage specifies a URL, it passes it through the resource method to get the "real" URL. Normally, these are turned into the normal ".nsf" paths, but there's no reason they have to be. Here's an example of the two methods in my project-tracking app (named "Milo"):

public String getResourceURL(final FacesContext context, final String resource) {
	if(!isGlobalResource(context, resource)) {
		// Then switch it to "/m/whatever"
		return "/m" + resource;
	return super.getResourceURL(context, resource);
public String getActionURL(final FacesContext context, final String pageName) {
	return "/m" + pageName + ".xsp";

I set up a substitution web rule on the server to translate "/m/*" to the full path of the DB. Because of this change to the view handler, now every <xp:link/>, <xp:image/>, theme resource, etc. uses the "pretty" path. Assuming I don't run into any major down sides, this is a huge piece in the puzzle! Now I can write my apps normally - referencing XPages, resources, etc. using the same portable, app-relative syntax as usual - and then let my ViewHandler determine if it should clean up the URL. This is a nice step above my second solution, which required either a special EL pattern or a custom control to translate the URLs; now that job can be passed up a layer of abstraction.

There are still two problems I know of standing in between me and using this everywhere: automatic detection of server support (e.g. reading names.nsf for matching web rules) and navigation between pages. Though the ViewHandler covers normal links and form action URLs, it doesn't handle navigation between pages based on navigation rules. I don't expect that to be an eternal problem, though; JSF has hooks for this sort of thing, so it should be a matter of figuring out how to use it there.

Overall, it's still something of an ugly solution: where other platforms have clean routing configs, XPages has a hodgepodge of server-level settings and in-app shims. However, I hope to turn it into a worthwhile combination of automatic configuration (by reading names.nsf) and clean declarative settings that I can build into the Scaffolding project.

Using a ViewHandler to Serve a Different XPage

  • May 3, 2014

I've been using a ViewHandler class for a while now for a specific purpose: injecting controller objects automatically. However, I hadn't really dug into them further than that. I should have, though: I spent a little time poking around this morning and found that they can help solve two minor annoyances I've had for a while.

For the purposes of this post, the pertinent one of those is the ability to serve a different XPage than the one requested. In normal cases, this isn't a particularly useful ability, though I can think of some pie-in-the-sky ideas like loading the compiled XPage classes from a plugin or Jar (like a homebrewed single copy design). Fortunately, I have an immediate use in mind: first-run config.

If you've used a package like WordPress, you've probably run into its first-run behavior, where it runs you through a wizard to set up the app configuration, database paths, and the like. Normally, this isn't important in a Notes app, but it's needed if you want to ship an empty DB and have people set it up for use. In my own case, I've taken to using a keyed document to store the app configuration, and this document doesn't exist when I reconstitute it from soruce. There are a couple ways I could handle this; for example, I could put code at the start of every page (or in each page's controller) to check for a completed config and, if not present, send a redirection header. Putting it in the ViewHandler, though, means each individual page doesn't have to care.

Here's the snippet of applicable code from my new ViewHandler:

public UIViewRoot createView(final FacesContext context, final String pageName) {
	if(!AppConfig.get().isComplete()) {
		return super.createView(context, "/appconfig");

	return super.createView(context, pageName);

Now I have my config bean do a self-check to make sure all the fields required for normal app operation are present and, if not, the code forces the config page to load in place of the requested one. It has the side benefit of not actually causing a redirection, and in that way it's similar to Domino's standard login and error forms.

While this isn't the sort of feature that's going to completely change the way I write XPages apps (most likely), it's good to know about one more ability.

Expanding your use of EL: Mea Culpa

  • May 2, 2014

A while back, a wrote a couple posts about using Expression Language (EL) to clean up your XPages code, and in the first of them I gave what I labeled an exclusive list of the interfaces that XPages EL provides special support for (as opposed to just looking for getters/setters). It turns out I was sorely mistaken: there are at least two other types that EL specially supports.

The first is the class used for JavaScript objects, such as allowing #{} to bind like you'd expect to a value set to the JavaScript literal { bar: 'baz' }. I'm not sure where the specific support comes in - presumably based on one of the classes in the hierarchy and not the IValue interface it implements - but it's not terribly important.

The second is an interface that I've used frequently, but didn't realize had this property: ViewRowData. ViewRowData is essentially a specialized variant of DataObject intended for view entries - so much so, in fact, that I just assumed that view entries supported DataObject simultaneously, as my classes that implement it do.

I don't expect I'll have a lot of situations where I'll want to implement ViewRowData but not DataObject, but it's good to know one additional tidbit about the inner workings of XPages. One day, maybe I'll try to find a truly exhaustive list of what gets special treatment.