Progress on the org.openntf.domino Design API

Sep 6, 2013 6:57 PM

Tags: java openntf

The primary focus of my recent work with the OpenNTF Domino API has been the implementation of a fleshed-out design API. I've done a lot of work in my Domino-programming career manipulating design elements, usually via DXL (such as with my Forms 'n' Views app), and my aim is to codify all of that into the API itself, eventually growing it to cover almost every design element that Designer does (we'll see about Navigators, Composite Apps, and the like).

One of the big hurdles in recent years when manipulating design elements has been dealing with XPages-related elements - XPages themselves, Java design elements, Jars, faces-config.xml, etc.. Though XPages by their nature have a very nice XML representation, that doesn't carry over to DXL - all of those elements are dumped out in the "raw" data format that DXL uses when it doesn't have a better idea of how to handle what you're trying to export. And more specifically, though the XSP markup and the compiled Java code are present in the result, attempts to actually manipulate that were stymied by a "checksum" block of bits at the start of the data - you couldn't just drop the Java bytecode into the doc and expect it to work.

Fortunately, it turns out that those bits aren't a weird "checksum" at all: the data is just stored as Composite Data, the internal format of rich text in Domino. Specifically, all of those elements share the same internal representation as File Resources and Style Sheets, being composed of a CDFILEHEADER and list of CDFILESEGMENTs. When DXL uses the "raw" format, it exports that data as an array of Base64-encoded bytes directly. After discovering this, I wrote the start of a CD implementation in the API and got it to work: the API is now able to read/write the attached data of any one of those file types. Now, there are a few steps that would have to be implemented between this and "write a new XPage with a few lines of code", but this is a step in that direction (and you could theoretically modify your faces-config.xml, xsp.properties, etc. on the fly now, though I haven't tested much).

More immediately, it's also a huge step in the direction of interesting read-focused uses. One of these uses in particular has caught my fancy: loading and using XSP-related Java classes in other contexts. To go along with my work, I wrote a DatabaseClassLoader that gives you access to all of those class types from anywhere using the API (including Jar design elements). The possibilities for this have made me giddy: re-using data-model objects in external scheduled tasks, sharing classes with Java agents (...with the caveat that you have to use reflection or a scripting language), "loading" other XPage apps from inside another, treating NSFs as replicating, access-controlled Jars, and so on. I have my own notions for some practical uses I may want to explore, and I'm very interested in seeing what kind of things this lets others do as well.

Commenter Photo

Kevin Pettitt - Sep 7, 2013 11:42 PM

This is great Jesse, keep up the good work. Really enjoyed your MWLUG session too!

-Kevin

Commenter Photo

Martin Pradny - Sep 9, 2013 3:48 AM

Thanks for this. I just tried to create fileresource with it and it worked like a charm.

Plans you have with it seem really promising. I really struggle when I have to share logic between agents and xpages using jars in jvm/lib/ext :( Database classloader would be great.

Commenter Photo

Christian Guedemann - Sep 14, 2013 6:03 AM

Jesse take a look inside of https://github.com/OpenNTF/XPagesToolkit. We find some lowlevel apis to write files into the nsf. Not all files are best transformed via DXL. We had some bad experinces with .properties files and after that I found a better way to write .properties files -> https://github.com/OpenNTF/XPagesToolkit/blob/master/org.openntf.xpt.core/src/org/openntf/xpt/core/properties/storage/StorageService.java

Hope this gives you an other idea :)

Best regards

Christian

Commenter Photo

Nathan T. Freeman - Sep 16, 2013 2:32 AM

@Christian an elegant way to address resources, but it depends on the use of the NAPI. One of the basic premises of the OpenNTF Domino API is that it cannot have any dependencies outside the base J9 JRE that ships with Notes/Domino. This includes all Eclipse & OSGi plugins for DOTS, XPages and Designer.

Commenter Photo

Peter Närlund - Dec 16, 2013 11:07 AM

I'm trying to read and update a FileResource but do not get it to work.

does anyone have a working example using org.openntf.database.design?

Commenter Photo

Peter Närlund - Dec 16, 2013 11:09 AM

That should be org.openntf.domino.design

Commenter Photo

Peter Närlund - Dec 19, 2013 7:49 AM

Thank you, Jesse for your email explaining that the user needs designer access to the database. And that I also needed to change Maximum Internet Access to Designer in the ACL for this to work.

I'm happy!

New Comment