Most of the time I'm contacted by a fellow yellowbleeder and presented with a question that has me asking two questions for their every one. I'm fine with this - don't get me wrong - as it's something that I do literally every day.

"Can this be done?" is often met with a "What are you ultimately trying to do?" and "How is this going to be used?" from me, as I find that most of the time a person is set on a way of doing things well before they even ask a question. Which - again, don't get me wrong - is fine, but as we all know there are about 50 different ways to get the same results, and quite frankly setting your mind to only one of those methods when looking to another geek for suggestions can often limit your end product.

This tutorial will showcase a simple NotesDocument auto-save engine for an example NotesDatabase using the Domino CRUD API. The desired user experience will have the user's non-submitted NotesDocument auto-save after an admin-defined interval. To ensure a seamless user experience, I will continually - via a JavaScript timer - submit the "uidoc" via HTTP POST through AJAX to the Domino CRUD API to create (or update) a "temp" NotesDocument. We will create a custom response message to the HTTP POST and return the "temp" NotesDocument Unique ID (UNID), which we will use to update the "uidoc" HTML Form Processing Agent.

What's this all about? This is my NotesDocument Auto-Save engine for Domino Web Applications, which is an online demo turned Lotus Domino Designer Wiki article turned downloadable example application. Check out a quick video I put together to showcase just how simple it is to provide your users with such a valued feature:

For those of you - like me - who prefer to download an example application:

And now you have no excuse! Go add this feature into your existing Lotus Domino Web Applications, and never again get a call from a frustrated user who just lost 6 hours of editing a NotesDocument via a Web Browser when your Domino session authentication times out after 30 minutes...

Author's Note: Let me start by saying that there is no total-future proofing solution for development on any platform. Things change, which we should all consider a really great thing or we'd be writing plug-ins for Microsoft Bob...

I was contacted recently by someone who is not what they would themselves consider a Domino Web Developer as much as they are a seasoned Lotus Notes Developer, who has a pretty immediate need to create Web Browser client front-ends for several production Lotus Notes Client applications.

The customer environment is not currently running Lotus Domino 8.5, so leveraging XPages to create a client-specific UI just isn't in the cards.

See, as both Domino Web Developers and Lotus Notes Developers we're living in some really interesting times. XPages - for the most part - herald the return to Domino Web RAD, allowing even those developers unfamiliar with the more advanced web development techniques and technologies (ie., JavaScript Libraries for rich UI experiences) a relatively simple WYSIWYG development experience.

We're also living in times where IT projects are often back-burner'd unless you can really justify a quanifiable return on investment.

Luckily, between XPages brining RAD back into Domino Web Application Development and DAOS - when implementing properly - drastically decreasing back-up times and working in-line with most corporate data retention policies, a relatively easy upgrade to Domino 8.5 isn't that hard to get through the uprights.

Of course, there are still those shops who just cannot upgrade their environments or those who prefer to not implement v1.0 features into their environment and therefor are waiting for Domino 8.5.1 to go Gold Release.

So, regardless of the why, there are some Notes Shops that just can't upgrade.

Does that mean that their customers/users should suffer? NO!

So, I thought I'd take a few minutes to discuss some strategies that I use to best future-proof my code to ensure that it's inline with the features and functionality that DDE and 8.5.n can deliver.

UI/Data/Business Logic Separation

Yes, I know - I've preached that sermon time and time again, but this is really the first step in future-proofing your applications.

I'll give you a real-world example here. Let's say you have a simple tracking NotesApplication, which is designed to allow a user to create a NotesDocument that tracks a given asset, and the NotesDocument is assigned a unique incremental key for tracking purposes.

Most developers would put some QueryOpen or QuerySave event, or a UI NotesDocument call to grab the next available number in the system. Simple stuff right?

Well, what if you need to write a Web Browser client UI for this form? What about a Mobile Browser client UI? What if I wanted to automate the creation of these assets from another system?

If you develop your business logic into the UI, you will need to re-develop it into every UI your customer/user audience demands. Not very RAD if you ask me...

Instead, I normally create a business logic engine that will allow me to submit the NotesDocument, and all applied logic is rendered against the submitted NotesDocument.

Consider this: if I decide to create a Lotus Notes client Wizard for the creation of these NotesDocuments, instead of dealing with ComputeWithForm nightmares and resaving the NotesDocument or something otherwise equally undesirable, I can just as easily submit a single NotesDocument or an entire NotesDocumentCollection to my business logic handlers. This makes the process of creating alternate UIs and alternate client UIs infinitely more simple.

Ok, I'll beat the dead horse here a little bit more:

Pretend I'm writing a JavaScript function to create a prompt message to the user:

function msg() {
alert("This is a message.");
}

Now, as silly as this sounds, what if I needed a prompt with a different message? What if I needed multi-language support for the application? Using the above approach, I'd need to create JavaScript function after function after function.

function msg(msgbody) {
alert(msgbody);
}

Sure, this is a simple change, but it's simple to further my point: using more dynamic architecture when designing the application - such as complete separation of User Interface, Data, and Business Logic - allows you to more easily deliver the solution that your customers/users demand!

Don't use RAD

Huh?! I hear you say. RAD is specific to the version of the given technology that you're using. Consider the way Domino Design Elements - designed for Web Browser clients via Domino RAD-techniques - rendered in Lotus Domino R5. Consider how they're rendering today. Now keep in mind that HTML 5, CSS 3, and various other influences are just around the corner...

Allowing the product to do the work for you is nice, but you quickly lose control over what's delivered to the Web Browser clients of your customers/users. When that happens... you're about a heartbeat away from saying "Sorry, Domino doesn't do that...".

Once you abandon RAD techniques and take complete control over what's delivered to the client - regardless of that client - you'll understand that it's all just markup in the end.

You're only limitations then are what the client can handle - be it the Lotus Notes, Web Browser, Mobile Browser, or any other client types.

So, how does this make your applications future-proof? Well, since you have complete control over what's being rendered to the given client... you don't have to worry about a patch fix breaking undocumented functionality that you were relying on to deliver the cobbled-together feature that your customers have grown dependant upon. You don't have to worry about upgrading systems, keeping your technology investments up to date.

... and quite frankly, if you are totally in control over what's rendered to the Web Browser client (for example), changes are the application will be done right and you can focus more of your time on new and exciting features instead of wrestling with RAD-generated content and trying to cobble together a hack that will deliver what you need.

And there you have it - albeit preachy - two tried and true ways to future proof your application development efforts.

If you're interested, and as soon as I get some time in my schedule, I'll work on getting a few examples put together of client-agnostic Business Logic engines and how you can use them in your day-to-day projects.