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.

Dave Leedy does it again - taking nine minutes to dive into Type Ahead-enabled Fields on XPages - showing the differences between Partial and Full Modes - and showing via screencast demo just how easy it is to use SSJS and XPages to create some truly functional Domino XPage web application user interfaces within minutes!

007 - Notes In Nine - A License to TypeAhead

Click here to subscribe to Dave's YouTube channel, and feel free to tell Dave just how awesome this series is by leaving a comment on his videos (or even better - sharing them via your blog, twitter, and facebook.

Also, in case you missed it in the video...

Notes in Nine - LIVE!

XPages: Notes Development meets Web 2.0

Two live shows:

• Thursday, October 15th, 12:00PM (Noon) EST
• Wednesday, October 21st, 08:00PM EST

Each webinar will be available at leonline.net, and - based on feedback and demand - may also repeat in November and December 2009!

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.

In follow-up to my post from the other day, I thought I'd pose the following question via Twitter:

Lotus Notes Client design question: Do you still use Framesets in your Application UI?

The response from both Twitter and the various other social networking sites prompted me to create a quick MicroPoll:

Now, understandably, this is a pretty wide-open alternative with Frameset vs. 'Web', but I have this idea...

Look at the more successful cloud service solutions out there today. You're presented with - in most cases - a 3-column fixed layout with highly-stylized UI interaction with various functional nodes. Navigation to top-sections is fairly basic, with in-content drill-down options to specific content or functional sections.

This should be fairly simple to re-create within a Lotus Notes Client application without the *[conventional] use of Frameset Design Elements.

* - Have to give myself an out if there comes a situation where I'll need to use a Frameset in some unconventional ways.

And I know this won't be possible for every application-type within the Lotus Notes Client, as certain applications have certain user experience expectations... which begs the questions for those of you who might answer "We have a corporate standard UI": maybe that's a bad thing in some cases?

In previous entries, we've discussed how to use the Domino CRUD API in the following ways:

• Understanding the Domino CRUD API - the Basics

  Where I first introduced and discussed the Domino URL Commands that you can use to interact with the Domino CRUD engine.

• Understanding the Domino CRUD API - $$Return Basics

  Where I showed you - via screencast - how to control the Web Browser client session post-NotesDocument Create/Update submission with the reserved $$Return NotesItem.

• Understanding the Domino CRUD API: $$Return and Smart Landing Pages

  Where I showed you - via screencast - how to use the $$Return NotesItem in combination with URL QueryString Parameters, Formula language, NotesDocumentUNIDs, and a Page Design Element to create context sensitive Smart Landing Pages for the Web Browser Client post-NotesDocument Create/Update submission.

Now I'll show how you can create your own non-Domino Form Design Element-based XHTML Form Elements that use the Domino CRUD API for NotesDatabase Data Management. In this, the Part 1 in a smaller part of the overall Understanding the Domino CRUD API series, I'll show you how you can create a simple Domino Page Design Element that can be used to Create and Update NotesDocument data.

NOTE: I'm opening up the Domino CRUD API Example NotesDatabase to Anonymous access having Editor w/ Delete. I'll keep it that way as long as we all play nicely. Someone playing script-kiddie and putting some cross-browser attack or posting inappropriate content will ruin this for everyone (as well as give me the burded of shutting things down). Should go without say, but...

First thing first, we'll talk about the ingredients for this build:

1. Page Design Element: content.html

   This is going to be - on purpose - a very basic build. I could get really creative with this XHTML (Content-Type: text/html) webpage, but that might distract from the overall example.

2. Input/Textarea Element name Attribute match

   This one is simple yet very powerful. If you're NotesItem is named title, your XHTML Form Element's Input Element name for title needs to be title!

3. NotesDocumentUNID passthru Logic

   Just like with the Smart Landing Page - which is a basic example of an advanced Domino Design Element-driven Domino CRUD Read - we'll be using a NotesDocumentUNID to drive the Update XHTML page Form population.

4. ?CreateDocument Domino URL Command

   We'll use this to facilitate the Create Domino CRUD verb.

5. ?SaveDocument Domino URL Command

   We'll use this to facilitate the Update Domino CRUD verb.

First, we'll create our simple content.html Page Design Element:

Simple, and will get the job done. Two major things to point out here: the Form Element's processing agent and the value attribute for each Input Element.

The Form Element's processing agent - as shown - uses a Computed Text instance to populate it's action:

~UNID := @UrlQueryString("UNID");
@If(~UNID = ""; "content?CreateDocument"; "0/" + ~UNID + "?SaveDocument")

This simply checks the URL Query String for a parameter named UNID. If found, I know I'm going to Update a NotesDocument. Otherwise I'm going to Create a new NotesDocument.

The Computed Text set as the values of our Input and Textarea Elements does someting similar (for the Title Input Element):

~UNID := @UrlQueryString("UNID");
@If(~UNID = ""; ""; @GetDocField(~UNID; "title"))

When we click submit - via the simple Input Element typed "submit" - we're going to rely on our XHTML Form Element's processing agent to handle the rest.

For new NotesDocuments, we see that it's pointing to the Content Domino Form Design Element and will issue the ?CreateDocument Domino URL Command. This will result on a NotesDocument being creating in the target NotesDatabase and leverage the $$Return to redirect our Web Browser Client session post-submission to our Smart Landing Page.

For existing NotesDocuments, we'll use the following syntax:

/0/NotesDocumentUNID?SaveDocument

Same thing here - the ?SaveDocument does the real work here via the Domino CRUD engine and performs an Update with the submitted XHTML Form Element contents.

NOTE: Notice the /0/ placeholder for the View Design Element in the XHTML Form Element's processing agent. If you replaced this with /pages/, it would honor the pages View Design Element's Form Formula, thus first rendering/submitting the NotesDocument via the display Form Design Element and - since there is no $$Return - would simply return the Form Processed message to the Web Browser Client.

The last part of this is to direct people to an edit link for each NotesDocument in your Pages View Design Element:

~t := @If(title = ""; "Untitled Content"; title);
~pl := "<a href=\"pages/" + permalink + "\">Use Permalink</a>";
~unidl := "<a href=\"pages/" + @Text(@DocumentUniqueID) + "\">Use UNID</a>";
~htmledit := "<a href=\"content.html?open&UNID=" + @Text(@DocumentUniqueID) + "\">Edit</a>";

"<tr><td class=\"col0\">" + ~t + "</td><td class=\"col1\">" + ~pl + "</td><td class=\"col2\">" + ~unidl + "</td><td class=\"col3\">" + ~htmledit + "</td></tr>"

The ~htmledit gives us the UNID URL Query String Parameter required for our Update, and the rest is handled by the Domino CRUD engine!

Wanna play? I've enabled Anonymous access to the Understanding the Domino CRUD API Example NotesDatabase. You should have Editor access with the Delete role enabled.

In our next entry - Understanding the Domino CRUD API: non-Domino Form CRUD Basics - Part 2 - we'll discuss how you can handle Read and Delete CRUD verbs - completing the Basics subsection of the non-Domino approach. After that, we'll get into some pretty advanced stuff!

Hopefully you'll start to see - especially after this - exactly where we can go from here. My XHTML Form was created in Aptana and outside of it's using Computed Text to populate the XHTML Form Element really wouldn't need to reside in a NotesDatabase at all. See... getting a firm handle on this stuff is the ground work for extending your Domino Web Application Development to new heights: integrating with other technology investments and SaaS/cloud services!