Domino Flex Fields (2)

11/03/2006 04:49 PM by Chris Toohey

In the last section, we discussed real-world drawbacks of User Defined Fields (UDF) as well as suggested the implementation of Domino Flex Fields to accomodate the need to have expanded data entry options. In this section, we'll discuss the fundimental architecture behind the Domino Flex Field.

The best way to continue with this methodology is to stop thinking like a Lotus Notes Developer. I know that for some of us we either can't help it (it's what we do after all) and for others we don't care to try... but trust me here - forget it and try this one out, I think you'll like the way it fits!

Think about a typical web portal. You have a single client interface for multiple applications. A typical portal solution can deliver applications like your email, your calendar, your contacts list, your group/team/business unit-specific forms, generated reporting and metrics, and pretty much anything - the portal allows the user to seemlessly access and utilize (or "should" I should say) a variety of applications regardless of their location, function, or in many cases backend technologies. For visual purposes, let's take a look at a VERY simple application of this logic:

Simply put, the consolidated UI interacts with various applications, all totally unbeknownst to the user accessing the portal.

Now, why can't we take that same approach with other solutions? Let's say... a common dashboard application that allows you to see your Inbox, your Calendar, your Contacts.... Well, we know that we have such a thing, bookmarks.nsf in the Lotus Notes client. But that submitted, let's keep going forward with this mindset. We have applications right now (we do it with RCRM for example, as do many others) that allow you to access consolidated data from various resources at the document level: Single Category embedded views that showcase, for the RCRM example, specific correspondence for the given contact from within the Contact form. This is a pretty slick solution as the user only needs to go to another tab on the Contact form to see what's been going on with the particular contact. This is a solid example of providing a single point of access to multiple solutions within a consolidated UI, but we can take this approach even a step further than that.

Before we do that, let's discuss RDBMS architectures to help us further illustrate the next step. Let's say we have two records which we want to combine into a single record for reporting/export. In most (if not all) RDBMS architectures, it's simply a matter of creating a BIND between two records that share a unique key. Now, just as this BIND would allow the Server engine to see the two or more records as a single record... we'll create an architecture that will allow the user to perceive two or more documents as a single document. Let's take a look at a modified (but still rediculously simple) representation of our intended architecture:

The above diagram, simple put, shows us what the user would see: they edit an individual "document", which updates various documents that comprise said "document".

Might seem overly complicated in truth, but this approach is actually very simple and allows you limitless expansion possibilities. Imagine a custom or 3rd party solution that you have in-house today:

User: "Hey, we need to start tracking Weight in ApplicationA!"
You: "Mmmmkay, how'd you get this number?!"
You: "Sure thing!"
You: Now, if this is a custom in-house solution, you add a field to the design of the form called "eyecolor". Yet. Another. Customization. If this is a 3rd party solution, we can simply grab one of the User Defined Fields... if there are any left. If not...
User: "Oh just use UserDefined01, we don't use that anymore."
You: So you change the label from "Eye Color" to "Weight", and get a call 6 months later...
User: "Why the hell do half of the reports say blue or green for Weight? Man, Notes sucks. Can't we implement Sharepoint 2008?!"

With Domino Flex Fields, you won't have to worry about a particular item being re-used, about running out of custom fields, or about having to make code changes to production applications. So, let's dive into the meat behind the suggestion solution:

We'll start with a given form, "Person" for this example. Let's create what would be our static fields for this form:

• FirstName
• LastName
• EmailAddress
• OfficePhoneNumber

Small list of fields, but that's the point. Your forms will now POP! But what about all the data that the users want to track? "Weight" and "Eye Color" need to be known! Well, that's where the Domino Flex Fields come into play. First however, we'll need to add another field to the "Person" form:

Now, with the UniqueDocID, we can create the functional bind between the Person document and the Domino Flex Fields - giving us a RDBMS feel for Notes data.

To do this, we'll create a pseudo-Parent/Child relationship between our Person document, and documents that will store Domino Flex Field data. In the example database, you'll see that the UI is designed to create a pseudo-child document from the Person document, it's given Field attributes controlled via a simple Configuration Control. What we did was to simply take another document from a "flex field" form, pre-populate a field named UniqueDocIDParent, and allow the user to enter the requested data.

An example of a "flex field" form would consist of the following fields:

Now, taking these field values, I could control the Field label, the content type (which in the provided example we addtionally controlled for data input purposes via seperate forms), and the actual field content. Now we have records that catalog elective data elements that can be bound to a parent based on a shared key (the UniqueDocId = UniqueDocIdParent, for this example). This allows us to look at the LND data as you would a traditional RDBMS solution:

The only thing left to do was to build a UI that would allow the Flex Fields to appear seamlessly to the given user - they see a single document while we maintain a slick UI that builds an array of relational data!

I'll elaborate more on these items, but I want to get this published and flesh out the afterthoughts and items for consideration through comments on this site!