Expanding Domino Applications via API and UI/Data Model Separation

02/29/2008 01:43 PM by Chris Toohey

The majority of the work that I've been doing lately is more (I'd say at least) advanced development than your more likely to see in your typical Notes shops. I say that, not to boast or brag - as outside of the Projects (both Yellowcake and Zephyr) - the work has been pretty standard customer applications. The advanced work has been more in the architecture of the applications themselves more than any cutting-edge coding that I've been doing. It's a change in the mindset of a typical Domino developer - most of you are probably already there, but there are those of you out there that still get caught up in the trappings of yesterday. Where are I going with this? Simple - understand that Lotus Notes and Domino applications really shine and become applications when you separate data from the user interface.

"Okay, you lost me..."

When you architect your applications so that data is presented and maintained as data, and not implicitly linked to the UI - your UI becomes a variable. This is an AMAZING option for your Domino applications. And this is (typically) done by defining a API, or Application Programming Interface, for your Domino applications. Simply put - you define (and then build) all of the data processing and maintenance elements for your given application, and then build your application to utilize said definitions/elements.

Take a look at Google Maps API for example. You have all of this data at your fingertips, and having a defined API allows you - the very capable developer - to build whatever UI you wish to access said data. Even better, the defined API allows you to integrate the application with countless other technologies.

You can see examples of this across the blogosphere - developers putting their component application development chops to the test and coming up with some amazing results. So why not take our Domino application development to the next level and define APIs for data maintenance?

And going this is, if you didn't hear this word enough already in this post, simple... at least after you get the hang of it.

Remove the UI from the equation - pretend you had to do everything from the back-end - now how are you going to create/maintain the data in your application? The answer, you'll tend to find, is maintenance of data via the combination of defined configuration document(s) and a commonly-accessible engine that utilizes said document(s) to create, modify, and delete data in the Domino application. And how do you display data in from a Domino database without hard-coding markup in NotesItems? Introduce translation layers for your data, which - depending on the given client type - can conditionally render markup and different content types.

Over the next few days/weeks - in between customer projects, the Redbook residency (which starts next week, btw!), Yellowcake, Zephyr, and a few other things that I have on-the-plate - I'll try to come up with a few rip-and-play examples of what I'm getting at here. Until then, expand your minds and start getting away from Domino development practices that brought you storing markup in fields and hacking Domino RAD-generated architectures to get slightly prettier Web2.0 UIs (both of which, I've done myself countlessly in the past).