Tip of the Iceberg :: the power of the extensibility API

Category xpages

Disclaimer: this post discusses features planned for version 8.5.2 of Lotus Notes and Domino. Version 8.5.2 has not yet been officially released. Ergo, what I'm about to describe to you may well vanish when the real thing arrives... if it does, I will be seriously tempted to continue using the beta version indefinitely. That is how powerful I consider the focus of this post to be.

You might well be wondering what could possibly temper my tendency to upgrade to each bleeding edge version the very moment I can get my hands on it. Back in April, I referred to 8.5.2 as "primarily a nuance release". Multi-threaded replication, purty icons... even updates to the bundled version of Dojo and the XPiNC XUL engine... nifty stuff, but that's all just polish. Polish, of course, is a very good thing. But these all absolutely pale in the face of the biggest change slated for 8.5.2: the XPages Extensibility API.

What is the Extensibility API? Simply put, it allows you to write your own controls.

No, I'm not talking about Custom Controls. I agree, the terminology is confusing: surely, if you're writing your own controls, those are custom controls, right? Well, yes, in a purely etymological sense, that's true. But in a Domino Designer terminology sense, this has (almost) nothing to do with the Custom Control design element that was added to the NSF model in 8.5.0. Nope... this is way bigger.

A Custom Control design element merely defines a wrapper for zero or more Core Controls as provided by IBM - panels, repeats, edit boxes, buttons, and so on - and a list of zero or more properties that can be passed to any instance of this wrapper to instruct it how it should behave differently from any other instance of its design definition. Additionally, a Custom Control may contain other Custom Controls, which in turn may contain others. By decomposing any structure you want to build down to its "primitives", you can develop rather sophisticated features in ways that allow you to later reuse each underlying layer of complexity to develop other features. That's pretty darn cool, but still has one limitation: dig deep enough in any such hierarchy, and all you'll find are a pile of Core Controls that IBM provides for you out of the box.

Not any more.

I'll say it again: the Extensibility API allows you to write your own controls.

When you look at the control palette in Domino Designer, do you see anything glaringly missing? Well, "glaringly" is a surprisingly relative term: each of us builds different types of applications upon Domino for different reasons, based on requests from customers, clients, partners, colleagues in the community... so each of us has different priorities that determine what we miss most. Some may be baffled that there is a View Panel control, but no Calendar View Panel. Others may wonder why there's no Outline - or any type of Tree Control, for that matter. Still others may wish that there were more social controls native to the platform, such as a "Share This" control, or a "Like" button, or even just a rating mechanism that allows a user to click one of five stars to indicate how much or how little they approve of something.

Again, you could probably create each of the above examples as a Custom Control. And then all you have to do to make use of each feature is copy the Custom Control - and every Custom Control in its hierarchy - to every NSF where you want to use that feature.

When you use the Extensibility API to create a control, however, the process is slightly different:

Write the code that defines the control.
Package the control into a "library" - this creates an Eclipse plugin that defines what controls the library contains: you can bundle as many controls as you like into a single library, or just create the library to contain one control.
Deploy the library to each Domino server that will host applications using controls in this library.
Install the library into Domino Designer.

Once you've performed those steps, the icon for each control in the library just shows up in Designer, no matter which NSF you're in. You can use these controls in any NSF without having to add any design elements to it. Reusability goes through the proverbial roof.

Still not convinced? Then allow me to offer one additional selling point for the power of this feature. Every control in XPages is based upon (in Java-speak, "extends") a Java class called UIComponent. If it's an editable control - what most of us would call a "field" - it extends UIInput, which in turn extends UIComponent. As a basic example, the edit box control is defined by a class called XspInputText (hence the xp:inputText tag we see when viewing the XML source of an XPage that includes an edit box). This class extends UIInput, which is what makes it an editable control. Naturally, then, when writing what I've taken to calling "library controls" (to distinguish custom controls that are packaged in a library as described above from Custom Control design elements), you'll extend UIInput if you want your control to accept input from the user, and extend UIComponent if you simply want to display information to the user... or do anything else that requires no input from them. But... there's nothing stopping you from extending XspInputText.

If you have a pet peeve with the way that the Date Picker works, you can simply extend XspDateTimeHelper and change the one aspect of it that bugs you. If you think something's missing from the Link control (such as an option to display an icon if the link points to an external site)... extend XspOutputLink and add that one missing feature.

Back when Notes 8 was originally released, I joked with some colleagues that sometimes it felt like the only reason IBM ported the Notes client to Eclipse was to dodge subsequent enhancement requests: "Don't like how feature X works? Write a plugin." Obviously that wasn't the case. But with the Extensibility API, the implication for XPages is the same, even though (I'm assuming) that wasn't IBM's motivation for creating it: if we aren't satisfied with the capabilities of the framework, we are being given the power to change it. No whining, no excuses, just make it do whatever we want.

And that brings me to the "bad news": as you've probably already guessed, to create a library control, you have to write Java. So this is the part of the post where I become an unsympathetic hypocrite: yes, it's hard. Do it anyway. Or others will. I know that's harsh, but it's the truth.

Over the last three years, IBM has demonstrated quite clearly to me that developers are not an afterthought. With the exception of providing thorough and accurate documentation, everything I asked for in that rant has since occurred. And, of course, I wholeheartedly agree with jonvon that they need to be marketing Domino as an application platform... I'd be ecstatic if they made messaging the afterthought: "What? Oh, messaging? Sure, Domino does messaging... anybody can do messaging. That's easy. Now can we get back to talking about what Domino does that nothing else does?" If you owned a nightclub and found out that you were losing business, would your first priority be to remodel the restroom? Sure, that room serves a necessary purpose, but is that really why your customers are there? And is that why others are going elsewhere? Of course, if that's all you're advertising, sadly, you might still be losing business to a nearby hotel bar just because the bathroom sinks there have gold-plated faucets.

But the point remains: they're about to give us one heck of a big gun for our arsenal. It'd be a shame if it sat on a shelf collecting dust simply because we couldn't find time to go buy our own ammo...

Comments

1 - @1 - Actually, that OpenNTF project is already underway. IBM has one ready to go when 8.5.2 ships. As for commercial libraries... well, stay tuned. Emoticon

For those that would like to see a more in-depth discussion and demostrations of the Extensibility API, you can come to our presentation at IamLUG next month. { Link } for more information.

Posted by Nathan T. Freeman At 08:35:19 AM On 07/01/2010 | - Website - |

2 - @Ian, most likely the latter: I had predicted a while back that we would eventually see ISV's producing libraries of Custom Controls that we could purchase. That hasn't happened yet, and I suspect part of that is because you can't "close" the source of a Custom Control. So, instead, we've seen some great Custom Controls show up on OpenNTF, and I assume we will continue to. Control libraries, on the other hand, are automatically closed source unless you specifically choose to bundle the source with the library plugin. So we may see some open source control libraries show up on OpenNTF as well, both as examples of how to build control libraries, and as extensions to the platform that are easier to reuse than Custom Controls. But I also believe that libraries are a better approach for an ISV - not just because they make controls easier to reuse, but also because it's easier to protect the intellectual property those controls represent. Incidentally, this is a perfect example of something that might show up in a Notes App Store that would not be specifically user-centric: some "enterprising" developer could identify a need that other developers have, develop a library that meets that need, and offer it for sale for $100. If every Domino developer in the world buys a copy, they've pocketed $10 million.

@Jeremy, can't wait to see what comes out of the ZetaOne labs... honestly, if ISV libraries do start to emerge, I'm guessing the controls I'll be the most impressed with will be yours.

Posted by Tim Tripcony At 08:49:13 AM On 07/01/2010 | - Website - |

3 - Does this mean that OpenNTF needs to create a new class of shared Custom Controls? Or might some more enterprizing developers create and offer an affordable Library of Xpages Custom Controls for those less Java-skilled developers in the community to use?

Posted by Ian Randall At 03:35:35 AM On 07/01/2010 | - Website - |