Building off of my example from yesterday, I thought that I would show you how we can quickly and easily create READ and UPDATE functions for NotesDocuments via calls to our (modified) HTTP Request Consumer Domino Agents. And, to spice things up, I thought I'd do it all via AJAX.

Build Synopsis

That's the end-goal - a simple NotesData table that will allow us to change the Status of a given NotesDocument.

To get to that goal, I'll take the Agent Design Elements from yesterday - creating one for the READ and another for the UPDATE function. But first I need to ready the Page Design Element that acts as the Default Launch Object for the NotesDatabase, which will act as the display for our NotesData table.

Phase One: index.html Page Design Element

The index.html Page Design Element - just like with yesterday's example - is extremely simple by design: I want to focus your attention to the functional capabilities of having your Web Applications (Domino or non-Domino technologies-based) interacting with the HTTP Request Consumer Agents.

We'll focus on the HTML Form Element and the JavaScript functions, as the rest of the HTML markup is either descriptive/introduction or my Paypal Donation stuff.

The HTML Form Element contains the following markup:

<form action="#" name="moddocs" id="moddocs" method="GET">

<div id="viewbody"> </div>
<script>getdocs(document.getElementById("viewbody"));</script>

</form>

The JavaScript functions - there are two - are:

var http = false;



if(navigator.appName == "Microsoft Internet Explorer") {

  http = new ActiveXObject("Microsoft.XMLHTTP");

} else {

  http = new XMLHttpRequest();

} 



function getdocs(target) {

  http.open("GET", "getdocs.agent?open", true);

  http.onreadystatechange=function() {

    if(http.readyState == 4) {

      target.innerHTML = http.responseText;

    }

  }

  http.send(null);

}

function moddoc(val, UNID) {

 http.open("GET", "status.agent?open&status=" + val + "&UNID=" + UNID, true);

  http.onreadystatechange=function() {

    if(http.readyState == 4) {

      getdocs(document.getElementById("viewbody"));

    }

  }

  http.send(null);

}

getdocs() simply grabs getdocs.agent Agent Design Element-generated markup and sets the innerHTML of the passed-thru HTML Object (via an AJAX call). moddoc() passes two values to the status.agent Agent Design Element: the new value of the status NotesItem and the target NotesDocument UNID (again, via AJAX). When it's complete, it runs another AJAX call to getdocs() to refresh the NotesData table.

All I need to do from here is make sure that my NotesData table has the markup it needs that wires into the moddoc(). Pretty simple, as via the getdocs() function I have absolute control over what's returned to the Web Browser Client.

Phase Two: HTTP Request Consumer Agents

The getdocs() and moddoc() simply require a modification to their respective Initialize subroutines to both deliver and update our NotesDocuments.

getdocs.agent Agent Design Element - Initialize

status.agent Agent Design Element - Initialize

... and that's it. The getdocs.agent Agent Design Element generates the markup that we need: the onchange event of each SELECT HTML Element passes the newly-selected value and the target NotesDocument Unique ID to the moddoc() JavaScript function, which calls our status.agent Agent Design Element. This processes the request - using the submitted UNID and status parameter values to find the target NotesDocument and update said NotesDocument status NotesItem respectively.

After that, we simply "refresh" the UI via another AJAX call... and we're done.

Online Demo, Example Download, and Closing Remarks

Again, for those of you who prefer an online demo complete with downloadable example, I've got you covered.

The code written in this series is - how should I put this - not ideal. In a "best practices" scenario here, you'd want to return something like JSON, and parse that JSON return locally. This code is about as simplified and straight forward as it gets - I didn't do anything that would subtract from the goal of this article: getting you to understand just what you can do with an HTTP Request Consumer Agent Design Element.

Hopefully, this is a simple enough showcase that you'll start delving into this practice yourself - regardless of your comfort level with LotusScript, JavaScript, HTML Method calls, and AJAX. It's really powerful stuff here, and your web applications will definitely benefit from the overall approach.

Notice I said web applications - which is the second time in this article that I haven't prefixed Domino as normal. I use this approach with Flash-based Banner Ads, simple HTML Forms hosted on IIS and Apache, and countless other scenarios. It's ultimately no different than using Google Web Services or any other SaaS or Cloud service. I take that back actually - using this approach, you can quickly and near-immediately bring Lotus Notes Client-only applications onto the Web and Mobile Browser Clients: simply point the target NotesDatabase to a different NotesDatabase, Domino Server, etc. and you have yourself a very powerful NotesData proxy on your hands...

As I am ever discussing the need to separate the NotesDocument from Form Design Element binding - in other words, separating UI from the DataStore - I thought that I'd pass you a quick tip.

First, the scenario:

I have a Lotus Notes Client-based application that contains a simple document approval engine. Each approval document is a response NotesDocument to the parent NotesDocument which contains the overall status and miscellaneous document data. There is a business logic to which NotesDocument and Form Design Element is displayed based on who you are in the system or the current state of the NotesDocument.

For example, while the NotesView shows me the given document, I might be launching my individual review response NotesDocument, or a reader response NotesDocument, or the actual document.

Use Form Formula? Well, I do... but not how you might suspect. See, remember that I might need to launch the document or one of it's specific responses (my review NotesDocument).

Simply put, I need to be able to control what's opened regardless of how it's opened.

The tip:

document is not a UI component per se, but rather a "stub" Design Element that relies on the application logic to render a given NotesDocument via it's PostOpen event.

Example A Sub Postopen(Source As Notesuidocument)

  Dim s As New NotesSession
  Dim w As New NotesUIWorkspace
  Dim rcol As NotesDocumentCollection
  Dim rdoc As NotesDocument

  Set db = s.CurrentDatabase

  Set rdoc = Nothing
  Set rcol = source.Document.Responses
  If (rcol.Count > 0) Then
   Call rcol.FTSearch(|[reviewer] = "| & s.CommonUserName & |"|, 0)
   Set rdoc = rcol.GetFirstDocument
   Call w.EditDocument(True, rdoc)
  End If

 Call source.Close(True)

End Sub

Pretty basic right? Well, here's the trick that will allow you to open that - in the above case - review NotesDocument with any Form you wish.

Example: Sub Postopen(Source As Notesuidocument)

  Dim s As New NotesSession
  Dim w As New NotesUIWorkspace
  Dim rcol As NotesDocumentCollection
  Dim rdoc As NotesDocument

  Set db = s.CurrentDatabase

  Set rdoc = Nothing
  Set rcol = source.Document.Responses
  If (rcol.Count > 0) Then
   Call rcol.FTSearch(|[reviewer] = "| & s.CommonUserName & |"|, 0)
   Set rdoc = rcol.GetFirstDocument
   Call rdoc.replaceItemValue("form", "reader")
   Call w.EditDocument(True, rdoc)
  End If

 Call source.Close(True)

End Sub

Pretty simple right?

This allows me to open rdoc with the reader Form Design Element.

The only caveat to this approach would be if I needed to actually save content back to rdoc but wanted to ensure that the form NotesItem wasn't overwritten with my reader value.

... which is something I'll save for tomorrow's post.

I came to a realization today that I'm doing it wrong!

I've been using Domino Designer in Eclipse for a while now - both in pre-release as a Design Partner and the Public Beta, and as my primary development environment for the past few weeks... and I've been using it how I've been using Domino Designer for years now. In fact, I had been using the Lotus Notes 8.5 client the same way that I have for the past few years. That is, I've been relying on the Workspace as my Home Page, right-click Open in Designer... as needed, and keeping my Lotus Notes and Domino applications grouped in Workspace via tabs with even further visual segregation of the chicklets through use of whitespace. And this worked for me! I was able to quickly get to any of the applications I was working on, that I needed to work in, and I had it down to a science! That is until my laptop's hard drive decided to die on me!

Now, don't worry - I was able to recover all of my data (thankfully), but I vowed from that point onward to force myself to use the latest features within the applications that I spend the majority of my life in... and to start that bold new venture, I went with a fresh installation of the Lotus Notes 8.5 client.

After the initial setup, I fought the urge to set the Workspace as my Home Page and went with "Basic". Doing so, I found a new trick for non-Notebook users who blog, and I found myself becoming more and more comfortable with this entry point into the Lotus Notes client. I did, however, have some frustrations with the DDE client - specifically the time it took to launch a given Notes Application. This is the real subject of this post - and only several paragraphs in! - and something that I would urge all of you to check out.

See, prior to about 30 minutes ago... I would open a Notes Application in Domino Designer as needed. When I was done with whatever I was doing in that given application, I'd remove the application from the Domino Designer bookmarks. Sound familiar?

Well, if you try to do this in DDE, pack a sandwhich! Each time you do this, DDE builds out the project... and you wait.

It got to the point that opted to run Domino Designer 8.0 on another laptop instead of dealing with this apparent lag.

I see now that I was being a stupid end user. I wasn't using the DDE client as designed! I wasn't using the features that would alleviate my problems, because I was stuck in the past usage experiences. I was using the Workspace all over again...

So what do I recommend? Well, try this out. Open in Designer a Notes Application in DDE. Now exit the DDE client. Now open the DDE client directly - from either the DDE launcher in the Open menu or from your system's DDE Shortcut. Faster huh? So the answer is to leave all Notes Applications in DDE. Every. Single. One. But that could very well make the DDE client unusable... or at least the Applications Navigator Pane.

The answer is to manage your Notes Application into Working Sets!

What's a Working Set? From Lotus Domino Designer 8.5 Help:

When working with applications, you may wish to group several applications together as a "working set." The Applications Navigator can use working sets to restrict the sets of applications that are displayed. If a working set is selected in the Applications Navigator, only resources, children of resources, and parents of resources contained in the working set are shown.

So, from the Application Navigator, select Manage Working Sets.

From here, you can create, edit, and even delete Working Sets.

You can easily select the Notes Applications you wish to include in a given Working Set.

Now, you can apply load your chosen Working Sets at will - allowing you to filter what Notes Applications are displayed in the Application Navigator Pane in DDE.

Pretty simple, yet allows you to not only alleviate the aforementioned lag when opening a Notes Application in Domino Designer in Eclipse for the first time, but this new evolution in the Domino Designer allows you to better categorize and structure you work. See, it's faster and smarter!

I feel like I'm growing as a person...