How many times have you created an email with a Button, which you've coded with Formula or - hopefully - LotusScript that's been designed to perform some function? And how many times do people just ignore those emails? Sure, they open the email once, but they never click on your button for whatever silly reason they have. Ultimately, you're hard work is ignored and didn't get the chance to do whatever you wanted/needed it to do.

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.

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...

I don't typically hock my wares on the blog, but I thought that this would interest the readership.

I'm currently putting the finishing touches on my latest application - Spread, my NotesData Export Engine for the Lotus Notes 8 (and above) client. This is a consumer-focused product aimed at... well, I suppose anyone who has to take content from a NotesDatabase and work with it in Microsoft Excel.

Today, it's going into Microsoft Excel. Tomorrow -- meaning phase 2 -- I'm going to expand the export capabilities to not only CSV but also OpenOffice and Lotus Symphony.

Some of you may be curious as to what it does: simple really. An admin will define an Export Template. That Export Template will consume a NotesDocumentCollection - either via a defined Application Profile and NotesDocument Selection Formula or at runtime passed via the Lotus Notes client UI (UnproccessedDocuments, etc.). The engine takes each NotesDocument and evaluates it against a defined subset of values that will make up the Excel spreadsheet.

That was all geekspeak for You can either select some documents from a view or just tell it which report to run, and it'll just export the info into Excel! The goal is to make it simple for people to generate reports from any Lotus Notes application, and to do that...

This application will be a Lotus Notes Composite Application, wired as a widget. Once this widget is installed, the idea is that you can select a bunch of documents, right-click, and select Export... from the pop-up menu. A prompt later - mostly asking what it is that you want to export - and you're staring at your spreadsheet complete with NotesData from your application.

I'll babble more about this, as well as talk about the build once the product ships... but I thought that I would show you the Lotus Notes client UI for the application itself:

I've tried to go with as much of a Web UI as I could in the Lotus Notes 8 client without impacting functional integrity -- the last thing this application needs is a flaky UI just because I want it to stand out.

The build is fairly basic - a single Frameset Design Element used as the Default Launch Object for the Lotus Notes Client (since you can't lauch a Form Design Element without relying on hacking), Embedded Views on the application Dashboard/Home page, and a simple-yet-functional interface into what I hope will be an easy to use yet extremely powerful Lotus Notes Client plug-in.

I'll be putting out the call for alpha testers soon, but anyone with export needs that can report bugs back to me please contact me.

This will be a product that I'll be selling -- still working out fair pricing and just what you get for said price, but talk of that will follow.

Also, I'll keep this as far from being a commercial and more focusing on -- when I do bring it up -- the development of the product, as I think that is the more interesting part of this whole exercise for my developer-minded readers.

Promising (and from the above screen shot delivering) a clearner UI, faster page loads, News Feed filters, and even more point-release features, Facebook 1.7 for Blackberry is looking pretty slick, and this Bold user is looking forward to the rumored September release!

Of course, it's still not the Facebook for iPhone UX...

[via Boy Genius Report]