Call to Action: Designer Lite Plugin

  |   Blog   |   2 Comments

At Engage I hosted a round table discussion titled “Domino Next Generation IDE“. The discussion was around giving / promoting CRUD API access to databases, views and forms, as well as managing scheduled processes (which in the NSF world is handled as agents). The discussion was useful and covered a number of aspects. Since then I’ve digested and distilled the feedback I received, done some further investigation, and put together a spec. That has now been published on OpenNTF’s Confluence. As the intro to the Space covers:

The Designer Lite Plugin is the outcome of thoughts after IBM Connect 2017, circulated in a round table at Engage 2017. The aim of the project is to provide API access (initially Java, eventually REST / GraphQL) to manage setting up an NSF to serve as a data repository for an application whose front end is not XPages, not Notes Client and not traditional Domino web. The code will reside in an OSGi plugin, but will be designed so that it could also be in a jar loaded into e.g. a Vertx HTTP server. The code is dependent on ODA and will be an extension of ODA. The intention is that appropriate functionality is disabled by default, enabled via notes.ini variables (following the approach of IBM Domino feature packs). The spec will be a living document.

The team will require developers, testers, documentation and users. It will require developers deploying to Domino, Vertx or other Java-based servers. To get involved in any capacity, please contact Paul Withers in OpenNTF Slack. Involvement does not expect any understanding of ODA. The intention is that the team is inclusive and will help anyone who wants to get involved, in setting up development and testing environments as required. The upcoming free developer server license will be a key element.

There are still some challenges to be investigated and overcome. Building a scheduler itself should not be too challenging. Building the GUI should not be a challenge, whether it’s in XPages or some other web framework (or multiple options). Loading and triggering the scheduled event code may be a little more problematic.

An interesting aspect that’s been added to the spec since Engage is the potential for SmartNSF support. After some investigation, SmartNSF seems to just contribute a file to the WebContent\WEB-INF folder. The builder just parses and tests the Groovy code for validation. And if the editor has quirks for DDE’s version of Eclipse, any updates needed for a more modern Eclipse version should also enable it to be available as a plugin for standard Eclipse. So it could be used an editor for the resource file that, via an API, gets loaded into the data NSF as an alternative to custom REST services.

Another aspect that’s been added is using the $TemplateBuild shared field to handle identifying the data NSF’s current version. This is something I read about some years ago on a blog post by Steve Castledine as a standard IBM technique for template versions and it seemed a sensible approach for this project too. ODA’s Design classes allow for creating Shared Fields via DXL, it’s just that the DXL code there currently doesn’t work with date elements in DXL.

A lot of the APIs are already in ODA (OpenNTF Domino API). I intend to look at setters for various database properties (e.g. “Compress Design”) in the coming weeks. Adding these APIs may also give benefit to developers beyond this project as well.

I will re-iterate what was said in the quote, that the team will need to comprise a variety of members – developers, testers, people to do documentation, users. I’m looking for anyone to get involved who wishes to. Yes, ODA is a leviathan, uses the scary technology that is Maven, is not fully documented and means using a number of new tools. What you get if you choose to get involved is my expertise on how to set it up, help answering any questions you have relevant parts of the API or about building and running tests outside of an NSF. It will require some effort on your part, but will add to your skills significantly, particularly if you’re not heavily experienced yet with Java (as I was when I started working on ODA). If you want to get involved, please contact me on XPages Slack or OpenNTF Slack.

AUTHOR - Paul Withers

Paul Withers has been an IBM Champion since 2011, has been an OpenNTF Board Member since 2013, has worked with XPages since 2009, co-authored XPages Extension Library and was technical editor for Mastering XPages 2nd Edition. He is one of the developers on OpenNTF Domino API as well as contributor to a variety of other OpenNTF projects.

  • Lars Berntrop-Bos | Jun 28, 2017 at 1:40 pm

    re: scheduling stuff: is the DOTS frameweok not reusible for that?

    • Paul Withers | Jun 28, 2017 at 1:58 pm

      DOTS has options for scheduling, but the DOTS infrastructure doesn’t have all the plugins the XPages runtime does, so code couldn’t necessarily be set up once and used for both. Plus I’m not sure the scheduling is totally robust (though Serdar has much more experience of DOTS than I do). There were a number of fixes in DOTS Extended project on OpenNTF and, to some extent, it’s still a bit of a black box. The HTTPService class can run code every 30 seconds, so we have a mechanism for scheduling that’s been used by quite a few developers. It’s what I’ve used for scheduling in other plugins. And Xots gives multi-threaded processing of tasks too.

Post A Comment