I was recently asked by two people how they could get a Domino Agent Design Element to consume an HTTP request. Well, I wasn't asked this exactly...

One Lotus Notes/Domino developer asked me how they could modify a NotesDocument via a web browser client when said NotesDocument is not in edit mode in the UI. He is updating several fields in the NotesDocument - via an Approve button - and ultimately has to redirect the user to a different URL post approval.

The other request was asking for a simple search form in a Domino Web Application... more or less. The original request was to submit the NotesUIDocument (if you will...) via @FileSave;@FileCloseWindow, capture the submitted request, not save a new NotesDocument to the NotesDatabase, run an Agent Design Element via the WebQuerySave Event on the Form Design Element, and do the voodoo that he-do from the Agent Design Element.

Over the past several years, I've come up with a different approach: Submitting an HTTP request to a Domino Agent Design Element... and doing whatever I need to do from there.

Now - before I get into this - some of you may have noticed that I keep referring to each Design Element in it's full name, ie., Agent Design Element. I'm doing this - and will continue to do so - to alleviate confusion. See... I'll be talking about an HTML Form Element interacting with a Domino Form Design Element via the HTML Form Element's Processing Agent, which is targeted at a Domino Agent Design Element. In other words, the Form will interact with a Form via it's Processing Agent, which points us to our Agent. So yeah, it's not like I'm doing this for the word count!

Build Synopsis

For our build example, I'm going to create a simple search facility via an HTML Form Element and a Domino Agent Design Element. To complicate my life make sure we effectively cover all HTTP POST and HTTP GET Method requests, the example NotesDatabase build will feature a unique HTML Form Element each running an HTTP POST, and HTTP GET, and even an AJAX-based interaction with our Domino Agent Design Element.

I'll break this build down into three stages. In the first stage, we'll create a simple HTML Form Element using a Domino Page Design Element that will submit our request to a Domino Agent Design Element. We'll build this Domino Agent Design Element in phase two, and complete our build... well, putting in some Domino-specific hacks to get everything to work via GET. That last part will make sense when this article's finished in that you'll know what I'm talking about - not that you won't see how frustrating it can be!

Phase One: HTML Search Forms

We'll start off by creating a Page Design Element named index.html, setting the Content Type to text/html, setting the NotesDatabase properties to use our index.html as the Default Launch Object (not really needed per se, but it makes everyone's life easier...), and after we've set the HTML Head attributes and the beginning of the Body Element, we can add the following markup:

<h4>HTTP POST via simple HTML Form</h4>
<form id="example_httppost" name="example_httppost" action="search.agent" method="POST">
<label for="example_httppost_query">Query</label><input type="text" id="example_httppost_query" name="query" value="" /><input type="submit" value="Submit Trigger" />
</form>

We'll add 2 additional forms to the index.html Page Design Element - one for HTTP GET via simple HTML Form and another for HTTP GET via AJAX - but as each require a minor tweak that we'll cover in stage three of the build. We'll stick with this one as it gets the overall concept across: we're building a simple HTML Form Element that will submit a request (via POST) against our search.agent Agent Design Element.

Take note of the query HTML Input Element (or Field). This field will contain our search criteria, and will be the sole piece of data consumed when the HTTP POST request is submitted to the search.agent Agent Design Element.

Phase Two: Creating the search.agent Agent Design Element

In this phase, I'll create a simple Domino Agent Design Element - written in LotusScript - that will consume the submitted HTTP requests. I've simplified this Agent Design Element, which consists three (3) Functions and the Initialize:

getvalue

unescape

ReplaceSubstring

Initialize

Pretty basic stuff. Each function really just supports the simple act of taking the Domino Agent's Session - evaluated to a NotesDocument via DocumentContext - decides whether it's a POST or GET Method-submitted HTTP Request, and returns a value accordingly. In this case, it's grabbing the query parameter and using it's correlating submitted value for an FTSearch against a NotesDatabase. For our example build, I'm pointing it to the Domino Server Directory (names.nsf), thus using this more as a NotesData proxy vs. having the FTSearch run against the HTTP Request target NotesDatabase.

I mention that so you can immediately see the extended potential of this approach: your target NotesDatabase doesn't need to be HTTP-accessible in order to return NotesData to a Web Browser or Mobile Device Browser client!

The query thus returns a NotesDocumentCollection, which I then iterate through to build my markup String - which I will Print directly back to the Browser Client.

... and that's pretty much it. There is one additional check... but that's for AJAX vs. POST/GET Method HTTP Requests. Since the UX requires a different Content Type and, well, a different construct of the markup Printed.

Phase Three: AJAX considerations, Domino URL Command hacks, and final tweaks

For the AJAX-based HTTP Request, I add a simple QueryString Parameter and value (AJAX=1). It's usage is fairly evident in the search.agent Initialize LotusScript above - if set, return a Plain Text series of HTML SPAN Elements. Otherwise, it's full HTML Print.

Another gotcha: Domino URL Commands. This was an interesting one. When submitting an HTTP Request via the POST Method, it's simple: QueryString parameters are ignored, and you can point directly to the Domino Agent Design Element name without the need for additional parameters (ie., search.agent). With the GET Method, that's not the case. The entire contents of the submitted HTTP Request are added to the QueryString - both parameter and value. This wouldn't be a bad thing if Domino didn't require a valid Domino URL Command to preceed any of these parameter/value pairs.

For example, if I submit via GET Method to the search.agent Agent Design Element, I'll get this: search.agent?query=blah. And this will fail with a Domino-generated error message telling you - in all it's H2 glory - that there's no such Domino URL Command as query. open is a valid cross-Design Element Domino URL Command, so I decided to go with that... but in order to front-load the parameter, I needed to add it to the HTML Form Element.

<input type="hidden" name="open" value="" />

Silly, but it gets the job done! The result is an ugly but fully functional Domino URL: search.agent?open=&query=blah.

This same consideration applies to the AJAX requests as they use the GET Method to communicate with the search.agent Agent Design Element, but for that we can simply prepend the AJAX=1 to the URL from within the AJAX function.

As for tweaks - this is LotusScript: make it do what you want it to do! Pretty basic functionality that just can't be achieved via the Formula that's supported over the Browser Clients. If you need this to update a given NotesDocument, you can either pass a UNID vs. the query, run a target-NotesDatabase.getDocumentByUNID(UNID)-lookup, and do to that NotesDocument what you will!

Online Demo, Example Download, and Closing Remarks

For those of you who prefer online demos: http://domino1.clearframe.net/httpconsumer.nsf/index.html. Note: I've changed the target NotesDatabase from the Server Domino Directory to the NotesDocument Auto-Save Example Domino Web Application. You have the ability to create/edit NotesDocuments in that online demo as well, so feel free to have at it!

You can also download the demo NotesDatabase by clicking thru to the online demo (see, making you chase it!).

Lastly, I created this article and demo to help Lotus Domino Web Application Developers extend their application capabilites and functionality. In corresponding with one of the developers who mentioned a need for this functionality, he stated that he would compensate me for any help I could provide. I'll tell you what I told him: I'm very thankful for the offer, but the best way to compensate me for something that you find useful on this site is via contribution/donation to the site. All monies donated to this site go directly back into the site. Now, while I'm lucky in that I don't have hosting fees to worry about, I do purchase software - such as the warez I use for podcasting/screencasting, editing, etc. And I'm also picking up additional gear as needed/desired, such as new headsets for said podcasts/screencasts, etc. Now, while I don't think I'll hit the numbers in the coffers to pick up some higher-end hardware (such as the Apple Touch and the entry-level development Mac rig that I've been flirting with picking up)... every little bit extra helps the P.O. go through my wife that much easier.

If you can't donate to the site, I'll take your feedback - which is even more valuable. Like what you're seeing here? Want to see something else? Let me know and I'll see what I can do!

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.

A better description, and a MUCH smoother process overall, v0.2 of xCopy comes with the following enhancements from the original:

• xcopy via Java Agents and Script Libraries
• Transaction Log documents via Java Agents and Script Libraries.
• Can now handle multi-thread large file xcopies.

And that's about it! Not a major release from a feature perspective, but certainly a major overhaul as I've ported the actual functional Agents from LotusScript to Java... with Tim's help of course!

New/first-time xCopy downloaders just download, sign, and go! v0.1 users: download, sign, change to a Design Template, change the extension from .NSF to .NTF, and run Replace Design!

If you have a need to either manually or automatically copy defined files to a defined target location, this is the app for you! If not, download it if for nothing other than a very simple example of Java Agents and Script Libraries. Feedback and feature requests appreciated.

I ran into a situation recently where I needed to start backing up my My Documents contents onto a network drive (which is a good idea of course). I wanted to do this as easily as possible, and without the headache. So I thought to myself that there HAD to be a way that I could schedule the execution of a simple batch file that I'd write that did this for me. After I wrote this - which took a few minutes, it's not doing anything outside of a simple xcopy command with some attributes - I thought to myself that there's an opportunity here for not only a configurable application but also a slick little sidebar application in Lotus Notes. A few hours later, I had xCopy v0.1, a pretty slick little utility. The hours came as the result of little UI tweaks, including something slick that I'm doing with the Transaction Logs Form Design Element, a nice little sidebar widget in the form of a Form Design Element, which showcases a configurable embedded frameset and "webby" tabbed-navigation. And like with Sorting Hat v0.1, I've added an About this Application element that includes an embedded Digsby chat so - from within the application - you can instant message the author (... me).

xCopy is a simple configurable xCopy client for the Lotus Notes client. By creating and defining xCopy Profiles, you can batch process your file backup or remote upload jobs. With the addition of the xCopy sidebar widget, you can easily kick-off these jobs, and modify both the xCopy Profiles and xCopy itself.

Have a Javascript Library that you want to easily maintain? Simply download your library updates, and your previously-defined xCopy Profile will incrementally update your Webdav-enabled Domino Application!

It's simple, easy to use, and full of solid development examples!

To "install" the sidebar, check out this quick tutorial on Creating Form Design Element Sidebar Widgets!

Feedback/suggestions appreciated!

While creating a redirection rule for http://www.media.yellowcast.net to redirect all traffic to the YellowCast media files to the BleedYellow.com environment (thanks Lotus911! You guys continue to rock!), I found myself using SOTU (my simple Remote Console Command and Reporting application) to issue the "tell http restart" commands. Today, I thought about how cool it would be to put that in the sidebar of my Lotus Notes Client...

I honestly don't know how an "end user" is supposed to do this sidebar widget adding (IBM - see how Google does it from iGoogle for a "how-to"), but I created a more simplified version of the "wizard" and added it as a Sidebar Widget - and for a first run I'm happy with the results:

Click the screen-capture below to see a full-screen Flash Demo of the SOTU Sidebar in action!

I've added this form to the v0.2 release of SOTU and will probably continue to improve both the Sidebar and the application itself. I've heard some great feedback and suggestions on this simple-yet-useful application, but always interested in hearing more. If you like it, or have a suggestion on a way to improve it - leave me a comment!