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!

This afternoon, while chatting with Joyce Davis about the agenda for our August 2009 Lotus Technical Information and Education Community Meeting, we had the following exchange:

Chris Toohey I worked on an article last night. Sure, might not be everyone's cup of tea but it's showcasing a development technique that will be the basis for future-proofing applications - regardless of the technology platform used. Readership so far is luke warm.

Joyce A Davis you posted it in the wiki?

Chris Toohey no, not too sure if it fits in there.

Chris Toohey it's stuff that, well, out of context would be confusing to say the least - it might be too niche.

Joyce A Davis Chris, nothing is too niche for the wikis. People won't read it if it's not interesting/important to them.

Chris Toohey ok, you've convinced me.

Admittedly, it wasn't a hard sell. I absolutely believe that the Domino Designer Wiki is an excellent resource for the greater Lotus Development community... but I was hesitant nonetheless.

I'll explain.

On my site, I can post whatever nonsense I want. I can post about some off-the-wall concept that's crawled into my brain that hour or bang out a few quick examples of the playground-level thing that I'm working on at the moment.

The idea of cross-posting my Now() + n series to the Domino Designer Wiki just never occurred to me, more because I felt that the Wiki is a location for more best practices approaches while (especially in this series) my work is often intended for non-RAD developers.

Don't get me wrong, I'm not trying to say that I'm some uber-l33t coder or something like that - I just don't that most of the things I discuss here will really find their way into the day-to-day development practices for the occasional reader of this site.

Back to the point: Joyce is absolutely correct. The Domino Designer Wiki is the perfect place to put such an article. It's not only a concept that I believe it, but it's something that - if properly adopted - can save a developer countless hours of hack-work to achieve the ever-changing functionality that your customers demand.

So I plan to cross-post each of my Now() + n articles to the Domino Designer Wiki, and have started with my first: Leveraging MVC-style design techniques in Domino Application Development.

This way, my article not only has the potential to reach more readers, but I can work with the Domino Wiki Leads - as I mentioned the other day - and get developerWorks Author Achievement Recognition Program points... for something as simple as copy/pasting my own content.

And I'm not the only one doing this. Another member of our community - who has recently been producing some truly amazing content - is in talks with the program leads to ensure that the cross-posting of his content is recognized.

So whether you run your own website or not, just keep in mind that no content is too niche, too simple, or too "well everybody knows that!" for the IBM Domino Designer Wiki.

Deleting NotesDocuments in a NotesDatabase via the ?DeleteDocument Domino URL Command is simple enough, but there are many things to consider - some of which I'll go over in this entry.

1. Click-Confirm-Delete

You're going to want to create a simple to use, simple to recognize NotesDocument deletion mechanism for your Web Browser Client UI. In the Understanding the Domino CRUD API Example NotesDatabase, I've setup a simple click-confirm-delete engine for submitting a Delete request to the Domino CRUD API (example pictured below).

This UI-driven Click-Confirm-Delete facility will - when the delete icon is clicked - use a JavaScript confirm prompt to drive the cancellation or confirmation of the ?DeleteDocument GET-method call.

As Stephan Wissel commented, a direct ?DeleteDocument URL link from your UI could prove problematic and is really not recommended. As a slight work-around, I'm building the call to the Domino URL command via JavaScript.

First, an additional column to my pages rendered View Design Element:

<td class=\"col4\"><img title=\"Delete this NotesDocument\" onclick=\"notesdocument_delete('" + @Text(@DocumentUniqueID) + "');\" src=\"pk_icon_delete.gif\" alt=\"Delete this NotesDocument\" /></td>

Combining this with a very simple JavaScript function:

function notesdocument_delete(UNID) {
var q = confirm("Do you want to delete this NotesDocument?");
if (q) {
  window.location = "pages/" + UNID + "?DeleteDocument";
}
}

And we have the first part of our NotesDocument deletion facility.

2. Post-deletion behaviour -- what now?!

You'll note, in the above notesdocument_delete JavaScript function, I declare a valid View Design Element for the window.location to issue the ?DeleteDocument Domino URL Command.

The defining of a valid, existing, and Web Browser Client-accessible View Design Element is required for the ?DeleteDocument. Failure to define a View Design Element will result in the following error:

A successful submission will look like this:

Since we wanted to make this NotesDatabase a Domino Web Application, we know that this type of behaviour just won't do! We'll want to create a custom deletion confirmation message and - in this case - redirect them back to the NotesDatabase default launch element.

To do that, I've created a copy of the confirmation.html Page Design Element, stripped all of the NotesDocumentUNID lookups, and renamed it $$ReturnDocumentDeleted.

The $$ReturnDocumentDeleted, not unlike the $$Return, is a special-named element that provides functionality in the Domino RAD engine. Simply put, the $$ReturnDocumentDeleted-named Design Element is returned post-successful NotesDocument deletion.

For the Understanding the Domino CRUD API Example Application, I'm using a Page Design Element. Technically, you could name any Design Element $$ReturnDocumentDeleted and that Design Element would be returned post-successful NotesDocument deletion.

NOTE: I could have just as easily re-written the confirmation.html Page Design Element to accomodate this functionality (and added an alias of $$ReturnDocumentDeleted) instead... but that might throw off future users of the examples.

That's pretty much it for the basics of the ?DeleteDocument Domino URL Command. The next part of the ongoing Domino CRUD API series will discuss Read and the various ways that we can pull NotesDocument data from a Domino Web Browser-accessible NotesDatabase.

Stay tuned!

I've been playing around with Jott later - which allows me to dial into a (free to setup and use) account, and either leave myself a simple message or send that message to one of my contacts. The coolest part - it doesn't send an audio clip of my voicemail, but rather transcribes (and pretty damned accurately I might add) your message into text.

It's pretty slick, and something that I've been using to take mental notes over the past few days.

Today - while playing around - I saw that you have the ability to basically create a contact in Jott that is basically a conduit to a Web Service! This means, with the addition of a few Domino Design Elements, I could easily create an alternate publishing source for content on this 'blog.

The Jott Developers Guide gives a pretty simple overview of exactly how this is done, and it looks like it will allow integration with any HTTP POST-enabed solution (and thankfully Domino allows POST!).

I'll play around with this over the next few days - around some major data architecture tweaks to Match Maker to get it juuuuuuuuuuuuust right - and report back my findings, as well as some code, for those interested.

Have had a few things on my mind... specific and not-specific to the work I'm doing with Yellowcake, so here's some questions, comments, and babblings:

1. Is there any reason that you can think of that you would not want to create a Full-Text Index for a database if it meant said database could be fully web-enabled with no customizations to it's design?
2. There's Domino Applications and Domino Databases...
3. ... that being said, everything that we do is basically moving text around. Whether that text is markup of a sort that builds the rendering engine for your applications or the actual data stored within!
4. The best thing that you can do is share your idea with like-minded people. Don't be intimidated, worried, or afraid your IP will walk...
5. If you have to worry about said person walking with something you're sharing with them... why do you even speak with them?
6. How many of you are into Video Podcasts? Do you prefer Audio-only? Could care less either way?
7. 16 Processor Ticks and <1 second renderings are great... but if you're new-hotness shows an Agent Done when something goes wrong, you're not finished!

That last one should tell you - I'm not done with Yellowcake. I'm currently working on some things, including accounting for PUT and DELETE HTTP methods (calling Yellowcake a REST API without such support is apparently a misnomer otherwise). I'm already giving you the ability to create, modify, and delete target Domino Database documents/data via GET and POST... but I want to make this as powerful and capable a solution as I can!