Tip of the Iceberg

Category xpages openntf
About 18 months ago, I created an OpenNTF project called Community Control Library. The fundamental reason for creating the project was my belief that the single factor keeping the Domino community from realizing the true potential of the platform is the assumption that the XPages Extension Library is the extension library, not an extension library. Let's briefly revisit its history:

1. IBM starts an internal project, code named "Porus" (in reference to the Greek / Roman god of plenty), intending to share the code on OpenNTF. The primary intent of this project, if I recall correctly, was to demonstrate the power of the XPages Extensibility API, which was added to Domino in 8.5.2. Publishing the source code for an expanded set of components, data sources, and more would provide Domino developers some best practice examples of how the platform can now be extended to our hearts' content.
2. IBM creates an OpenNTF project to distribute what had previously been called Porus. The project is now known as the XPages Extension Library. As more and more developers download and explore the features made possible by this library, those whose organizational policies prevent them from doing so begin to demand an "officially supported" version from IBM.
3. IBM releases Upgrade Pack 1 for Domino 8.5.3, which consists almost entirely of a version of the XPages Extension Library that they are able to officially support. They continue to periodically publish new releases to the OpenNTF project.
4. IBM releases a public beta of Domino 9, which will bundle the newest officially supported version of the XPages Extension Library... no Upgrade Pack required.

When I created the Community Control Library project in 2011, I had lofty intentions of turning the project into the central place where the XPage development community goes to contribute, and consume, extensions to the platform beyond those already provided by IBM. But life got in the way and I never actually created the library. Recently, however, I was reflecting on the irony of the last item in the above list, and decided to revisit the idea.

You may well be wondering why I consider the above progression ironic. Or, quite possibly, chiding me for my incorrect use of the term. Unless I imagined this, the whole point of the XPages Extension Library was originally to demonstrate that we can add globally reusable artifacts to the platform. Then it became an add-on to the product that customers could file an SPR against, relinquishing all control over the library's behavior and stability back to IBM. Now (or rather, whenever Domino 9 is released), it's just part of the product. It's no longer really an extension library: it's just more features developed by IBM, supported by IBM. The platform is more than what it was before - as it is with every new release - but it's still the base platform. If you install Domino, you have this library.

DISCLAIMER: The intent of this rant is not to be ungrateful. The capabilities provided by this library are amazing. The features we can now rapidly and easily include in our applications continue to boggle my mind when compared to the original set of 38 components and 2 data sources that shipped with 8.5.0. I'm also intensely glad that this library will be natively included in 9; as long as a customer is running that version, I will no longer have to persuade them of the value of installing the library, because they will have already installed it. I can simply deliver more value to them than I otherwise could. This is all awesome.

But it still dilutes the truth that XPage applications can include components and data sources (and EL resolvers, view handlers, phase listeners, resource providers...) that IBM didn't develop. The Extensibility API is there for us. Yes, IBM can also use that to make it easier for them to add new features that they will support. But the primary reason the API exists is to give us more control over what the platform becomes.

The XSP Starter Kit makes it dead simple to create your own extension library. What it doesn't include, however, is an abundance of obviously useful artifacts that IBM will almost certainly never fold back into the product. So that's what I want to create: a library that, by virtue of always remaining a separate add-on, underscores the point that anyone can create this type of library. Here are just a few examples of what I envision including in this library:

• Custom Controls already published in the Apache Catalog on OpenNTF, converted to library components to allow them to be used in any application without having to paste them into each NSF and manage design inheritance.
• Components corresponding to HTML5 tags such as audio, video, and canvas (the latter of which is already part of the XSP Starter Kit).
• Data sources that provide simple consumption of YQL and other APIs.

I'm maintaining this library out on GitHub. Declan has already added some controls to it. Let me know if you have any feature requests (e.g. which Custom Controls from OpenNTF are already your favorites) or, even better, if you'd like to be granted commit access to the repository so you can donate features of your own. I'll periodically post releases to OpenNTF that will include built plugins in case you just want to install the library, but you can pull the source from GitHub at any time if you just want to look at the code or build the plugins yourself.