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.

The other day, I took a 2-day course on Time Management, where I basically learned that my procrastination and misuse of time causes me to be inefficient.

I also learned something that we may all know, but it (at least for me) didn't really hit home: we all get the same number of hours in a day, and time is a finite resource.

One of the take-aways from this course was that I should be using technology to make me more efficient. Notice I didn't say productive, but rather efficient. See, smashing my head against a wall for an hour will produce a bloody mess... it certainly doesn't make that hour an efficient use of my time.

So I've started using more and more of the Calendaring & Scheduling capabilities in Lotus Notes... and not just for meetings and appointments. One of the things I learned is that I need to start allocating time within my schedule to do the things that I need to do - if I need 2 hours to put together a project plan for an upcoming project, I should be blocking out 2 hours from my daily schedule solely for that activity, and treat that allocated time the same way I would a normal meeting: focus on the task at hand, and use the time as efficiently as possible.

I've also started to better leverage the To Do functionality in Lotus Notes - I am tracking individual tasks, marking them complete as I go.

I learned that - for procrastinators like me - creating and well-documenting a task list (making sure to put priorities against each task and ensure that each works towards the project goals) is the best way to both keep focused and ensure I do the items that must be done, not the ones that look like the most fun.

So every morning I have 30 minutes blocked out of my schedule to put together and/or review my daily task list.

Another exercise that is intended to help me see my time wasters - which was recommended both in the training literature and by the instructor - is to keep a time diary. The idea is simple - write what you're doing, when you're doing it, and whether that was an efficient or inefficient use of my time.

At the end of a given day, I should have all of my time for the day accounted for - allowing me to see (when compared against my calendar and task list) where I succeeded and where I failed to make the most out of my time.

... so why am I bringing this up here? Well, aside from the fact that I don't think I'm the only procrastinator here and thought that sharing this information could prove invaluable... I honestly couldn't see myself keeping an ongoing diary of my time.

At first, it felt really weird; like I was spending more time working on the diary than working on... work.

Then I remembered - I'm a developer. There's gotta be a better, easier way of doing this.

So I created Time Tracker, a personal time-tracking productivity application for the Lotus Notes client.

This is a simple Lotus Notes Client Application that allows me to create time log entries, categorize each as Efficient or Inefficient, and mark the start and stop times of the given activity.

Where this really comes in handy is Sidebar Widget:

Again, simple: enter a description for the time, and hit the Efficient or Inefficient buttons. If it's the first entry of the day or if you check off the checkbox on the right-hand side of the description, you're presented with a dialog prompt asking you to set the start and end times.

No check in the checkbox or if this isn't your first of the day? It uses the last time entry as your start time and Now() as your end time, and tracking your efficiency becomes a 1-click task!

I plan on publishing this application once I work out a few kinks (mostly in the Calendar View - nothing major, just not quite there yet from a UI standpoint). It will be a freeware/Open Source application, and I'm thinking of wiring some Readers fields into the backend - defined/toggled via the Preferences - that will allow you to easily put this on a Domino server and have multiple people enter their entries into a single application instance.

Thoughts? Features you'd like to see? I have some time available in my schedule coming up next week where I plan on finalizing the v1.0 release, so let me know what you'd like to see!

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

For those of you who don't follow me on twitter or are one of connections on facebook, you may have missed my call to test out my NotesDocument Auto-Save Online Demo:

While I'm taking the family to Go-Karts, check out my Online Domino NotesDocument AutoSave Demo @ http://bit.ly/BfEfv (just play nicely)!

Those beta testers (thanks gang!) confirmed that it's working like a charm... but I wanted to broaden the test group (as well as give you a live demo of a fairly basic but pretty slick Auto-Save feature that you can easily add into your existing Domino Web Applications.

The concept is pretty basic: When enabled on a new NotesDocument, the Auto-Save is triggered every 5 seconds. The Auto-Save submits the uidoc (go with me here...) via an AJAX-based HTTP Post - if it hasn't been saved yet, it submits to temp?CreateDocument, otherwise it submits to 0/<NotesDocument Unique ID>?SaveDocument. Post-submission, the AJAX POST returns the submitted NotesDocument Unique ID to a field on the HTML Form element named UNID (and that's you-nid btw...).

When you actually attempt to submit the HTML Form, it checks the UNID HTML field. If it's blank, it submits to document?CreateDocument, otherwise it submits to documents/<Value of the UNID HTML Field>?SaveDocument. (There's a Form Formula on the documents View Design Element that handles the submission. Same goes for the Auto-Save; it first checks the UNID before it submits - hence the @IsNewDoc-like functionality.

The reason why I went with this approach will be clear once the article is published... which will be soon after I return from vacation. Said article, and the downloadable example NotesDatabase, will be available on the Lotus Domino Designer Wiki.