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.

Learn how you can return custom NotesDocument submission messages and redirect to specific URLs with the Domino Rapid Application Development (RAD)-friendly $$Return.

This screencast, running 3:55, just touches the surface on what you can do with a $$Return in the world of the Domino CRUD API.

IBM Lotus Notes/Domino has a pretty easy to use and powerful CRUD - or (Create, Read, Update, Delete) NotesDatabase Data Engine - complete with a defined Web-accessible API.

The best part is... the majority of Domino Web Application Developers are already using it!

Note: I'll be using the term processing agent below. This is not to be confused with a Domino Agent Design Element, but is rather the XHTML Form Element's action attribute. See http://www.htmlquick.com/tutorials/forms.html for an example.

I'll make no assumptions here that you're familiar with the Domino URL Commands that handle all CRUD activities and just jump into them, as understanding them at a very basic level is required for a few more deep dive things that I want to get into. Thus, I'll list the Domino URL Command and how it's used below:

• Type: Read

  ?OpenDocument
  Usage: http://server/database/viewname/notesdocument?OpenDocument

  This Domino URL Command allows you to open or read a NotesDocument. This URL Command can be ommited, as the default render option for a Form Design Element when viewing a NotesDocument via the Web Browser Client is to open said NotesDocument in Read Mode.

  It should be noted that the Form Design Element used to render the NotesDocument will render in the following order:

  1. Form Design Element defined in the Form Formula section of the viewname View Design Element.
  2. Form Design Element defined in the Form NotesItem of the rendered NotesDocument.
  3. The Default Form Design Element for the target NotesDabase.

• Type: Create

  ?CreateDocument
  Usage: http://server/database/formname?CreateDocument

  This Domino URL Command allows you to create a new NotesDocument in the target NotesDatabase via the Form Design Element defined in the URL. HTML Input and like elements (fields) with exact name-match to NotesItems in the defined Form Design Element will exchange data.

• Type: Read

  ?EditDocument
  Usage: http://server/database/viewname/notesdocument?EditDocument

  This Domino URL Command does two things:
  1. Verifies your access to render the defined NotesDocument in Edit Mode.
  2. Renders the defined NotesDocument in Edit Mode via the same applied Form Design Element Logic as the ?OpenDocument Domino URL Command. (see above)

  This Domino URL Command does nothing functional per se, as it is used more to verify editor-access to the defined NotesDocument and tells the Domino to render - as mentioned - the NotesDocument via the Edit Mode version of the aforementioned logic-driven Form Design Element.

• Type: Update

  ?SaveDocument
  Usage: http://server/database/viewname/notesdocument?SaveDocument

  This Domino URL Command allows you to update the defined NotesDocument in the target NotesDatabase. HTML Input and like elements (fields) with exact name-match to NotesItems in the Form Design Element rendered via the aforementioned Form Design Element rendering logic. (see above)

• Type: Delete

  ?DeleteDocument
  Usage: http://server/database/viewname/notesdocument?DeleteDocument

  This Domino URL Command allows you to submit a deletion request for the defined NotesDocument in the target NotesDatabase. Simply put, if you have the proper level of access to the NotesDatabase (and to the NotesDocument), once you issue this request Domino will take care of the rest.

So that's pretty much it for a basic overview of the Domion URL Commands that run the Domino CRUD engine. Simple - hopefully - because you're all familiar with them due to their extensive usage in Domino RAD.

For example, if you look at the HTTP Form Element's processing agent for most Domino RAD-generated Forms, you'll see these Domino URL Commands in-use.

I think understanding the Domino CRUD API will enable you to both write better, richer, Domino-based Web Browser Client User Experiences as well as give you an eye to what can be done via simple integration with other/non-Domino technologies.

Hopefully this is useful to those of you looking to get into Domino Web Application Development, and the next few posts on this topic will act as a refresher for those old hands that have been doing this for years... but I went back to the basics because, well, that's for the next post!

As I've mentioned before: surround yourself with brilliance, and sometimes you get contact-smarts! ;-)

Tim and I were discussing a while back how he had built an application that would allow him - during a new project meeting - to literally build a Lotus Notes client application via a simple checklist of common design elements and various components. The result was a huge jumpstart to a new Lotus Notes project application, which would often require nothing more than some minor tweaking to get something that you can put in front of the project champion.

So the other day it hit me - if you had two NotesApplications - one to act as a simple container of design elements that were in themselves "components" of various NotesApplications, and the actual functional "utility" application that did nothing more than list said "components" and design elements with descriptive information... combined with a New/Existing NotesDatabase "builder" wizard - well, that would just rock!

So it's with that in mind that I annouce Project Nexus - the next utility application that I'll be working on here outside of a few updates to Showtime and SOTU that are well overdue in this developer's opinion. But I'm getting off topic here.

For those of you who (like me) enjoy pretty pictures:

Here we see a user (Mr. Gray), completing the wizard from the Nexus Utility NotesApplication by selecting the "Descriptive Components" entries. So, for example, Mr Gray wants the ability to easily export NotesDocument data from your "Target NotesApp" to Microsoft Excel. One of the "Descriptive Components" entries is titled Excel Export Templates. Once selected, the "Utility Build Engine" would then grab the Design Elements from the "Nexus Storage" NotesApplication - said Design Elements defined as a list in the Excel Export Templates entry - and copy them directly into the "Target NotesApp".

With this utility, you'll not only be able to ramp up your Lotus Notes/Domino Application Development Projects, but you can easily establish a solid enterprise-level development architecture for your organization.

Now I just need to find the time to build it ;-)

Comments/Suggestions/Feature Wishlist in the comments - this will be your application after all!

Here's a 52 second Jing videocast showing how you can add a Lotus Notes Form as a Sidebar Widget. Once you check that out... you may be interested in what went into the design of said Form Design Element.

I'll use SOTU v0.2 as my example here, so if you haven't already, go download it so you can play along at home...

So first, I created a pretty simple Form Design Element named "sidebar_remotecommand":

Pretty simple stuff. SaveOptions prevents the Form from being saved back to the database, and my Process button looks like this:

Sub Click(Source As Button)

	

	Dim s As New NotesSession

	Dim w As New NotesUIWorkspace

	Dim db As NotesDatabase

	Dim doc As NotesDocument

	Dim uidoc As NotesUIDocument

	Dim vw As NotesView

	Dim scol As NotesDocumentCollection

	Dim sdoc As NotesDocument

	

	Set db = s.CurrentDatabase

	Set uidoc = w.CurrentDocument

	Set doc = uidoc.Document

	Set vw = db.GetView("servers")

	

	Forall server In doc.GetItemValue("servername")

		

		Set scol = vw.GetAllDocumentsByKey(server, True)

		Set sdoc = scol.GetFirstDocument

		

		Call genResponse(sdoc, Cstr(server), doc.GetItemValue("command")(0))

		

	End Forall

	

	Call uidoc.FieldSetText("servername", "")

	Call uidoc.FieldSetText("command", "")

	Call uidoc.Refresh

	

End Sub

... yeah, that's about it. I blank out the fields and refresh the UI so that the "reports" from the processed remote console requests are displayed directly in the widget.

This is an EXTREMELY powerful combination of current subject expertise and this new entry-point into our applications - I'm now running around like a madman creating RAD widgets for all of our applications without the need to ramp-up on Java Sidebar Application development.