jump to article
...intermittent thoughts

XPages Extension Library from OpenNTF is huge

During Powersphere in Paderborn yesterday, I had the opportunity to speak with Niklas Heidloff about the just released XPages Extension Library. What I have seen so far has just blown me away and I am constantly getting new ideas of what's going to be possible with that. This stuff is awesome and beams XPages development into another dimension.
While it is not that easy to install the Extension Library, it is well documented on how to do that - I am still at the beginning of the >70 pages documentation. After the install, using the Extensions works like a charm. Very interesting to me is the use of the XPages Extensibility API and the availability of the source code - that way it is a perfect tutorial on how to use the API for your own extensions. I spoke to several developers yesterday and all of them were excited to get their hands on it - just like me ;-) Sure, the things that are possible with the XPages Extensibility API used in the XPages Extension Library are tough if you are not a Java Geek - but its so totally worth looking into it! But even if you are not the crack that is easy with exploiting new opportunities of API based extensions, the library is so helpful by providing new elements to XPages that were previously comparably difficult to accomplish. You should definitely have a look at it. Great stuff!

News on @WebDbName for XPages

Last week I posted some reusable, hand crafted @Function for XPages. Well there was a small mistake in it, I did not realize earlier. @WebDbName is written differently :-) So here is pretty much the same function - with correct spelling of the name:

* provides functionality of the function with same name from @Formula
* @return the name of the current database in a websave format
* @author Michael Gollmick
* @version 1.2
* @date 20090127
function @WebDbName() {
        try {
                if (typeof this.name === 'undefined') {
                        var path = database.getFilePath();
                        var re = new RegExp("\\\\", "g");
                        path = path.replace(re, "/");
                        var arr = path.split("/");
                        for (var a = 0; a < arr.length; a++) {
                                arr[a] = escape(arr[a]);
                        this.name = arr.join("/");
        } catch (e) {
        return this.name;

Besides of that correction of the spelling, I am thinking about a potential problem: what if IBM is releasing a newer version of their @Formula library containing an implementation of @WebDbName? Well, applications relying on this solution should run, since the custom function declaration should overload the initial definition - but what if such a potential native implementation works somewhat differently? That would be horrible for anyone who attempts to maintain legacy code, relying on an implementation as I just showed up above. One possible solution would be to name such functions differently. Well, that would work but would not be that easy. How to make such functions better remarkable to those who are getting used to XPages and come from an @Formula background? Daniel mentioned, to add some suffix to the function name, so that would probably be @WebDbName_MGO(). Good Idea, but I think this will look odd in the code. My current thoughts tend to rename this function to $WebDbName() and name future other implementations of known @Formulas also with a $ symbol at the beginning. They would then become the $Functions ;-)