dominoGuru.com

Your Development & Design Resource

Thoughts on Future-Proofing NotesData for Application Development

Despite the name change, most IBM Notes Domino developers are still developing "databases" vs. "applications". Whether they're using new or "traditional" design elements, they are using "traditional" methods and architectures for their apps... which could prove costly both in Domino application platform maintenance and potential future "porting" of said app.

In other words, most of these developers are still writing their apps assuming the data will always reside within a NotesDatabase and surfaced via Domino, and they do not take into consideration the need to eventually migrate that data to another platform - whether inside or outside of the IBM Collaboration Software product portfolio.

I'll give you a rather simple example that we've all either created or copied into our designs in our many years of Notes application development: a "Modified History" field. This notesItem, we'll call it "documentHistory", typically contains a timestamp of when the NotesDocument was created/modified and the name of the user performing the action. Standard stuff really...

You more than likely did this with a computed, multiple-value text "field", which appended a string via @Formula that read something like @Text(@Now) + " - Modified by " + @UserName. And that works, but it's sloppy.

What if you need to go multilingual? What if you simply wanted to change the action verb from "Modified" to "Updated" or "Changed"? What if you wanted to change the date formatting from hh:mm:ss MM/DD/YY to simply hh:mm MM/DD/YYYY?

My fix for this over the past several years is to simply store simple data in a delimited format which I use to create a pseudo-data table of the transaction. In other words, I store just the timestamp and the username, separated by a | (vertical pipe character).

notesDocument Properties Dialog - documentHistory notesDocument Properties Dialog - documentHistory

notesDocument Properties Dialog - documentHistory (more) notesDocument Properties Dialog - documentHistory (more)

Now, to display this, we'll use a simple Repeat Control (xp:repeat) and a few Panels (xp:panel) controls to create an unordered HTML list:

This results in the following dump of values from the "documentHistory" notesItem on an example notesDocument:

Example 1 - HTML Unordered List of documentHistory notesItem values Example 1 - HTML Unordered List of documentHistory notesItem values

Not the prettiest thing, but we're far from finished. Since the values are stored in the multiple value notesItem and themselves using a defined delimeter, we can use a series of Computed Text controls (xp:text) to reposition the data, apply filters (converters), and more! Let's take a look at an example of a more structured version of the unordered HTML list:

-- which results in the following:

Example 2 - HTML Unordered List of documentHistory notesItem values Example 2 - HTML Unordered List of documentHistory notesItem values

And now for some CSS:

-- which results in the following:

Example 2 - CSS styled HTML Unordered List of documentHistory notesItem values Example 2 - CSS styled HTML Unordered List of documentHistory notesItem values

Conclusion

While this isn't the greatest bit of code in the entire world, I think it perfectly illustrates a problem with the way most developers think about notesData and a way to move forward.

We often mashup our display content with our data, which can result in headaches down the line when you need to update the application or potentially port the data to a new system. You'll spend more time scrubbing data (or worse, abandoning data) than working in the updated/new application/platform/et al.

With the approach for our documentHistory above, moving the creation and modification history of an individual notesDocument to a Response Document architecture or creating an external notesDatabase that houses that data is extremely simple... as is exporting the notesItem data into a SQL data table that can be joined to the main record should you need to port to a relational data store.

When we talk about Future-proofing our applications, data architecture and the realization that storing the purest data possible (eg., not storing Common Names, not including UI content mixed with our notesData, etc.) is just as critical to project success as is maintainable user interface and user experience designs.


About the author: Chris Toohey

Thought Leadership, Web & Mobile Application Development, Solutions Integration, Technical Writing & Mentoring

A published developer and webmaster of dominoGuru.com, Chris Toohey specializes in platform application development, solutions integration, and evangelism of platform capabilities and best practices.



More from dominoGuru.com

dominoGuru.com is powered by IBM Notes Domino XPages & hosted by Prominic.NET

Contact Us

Use our Contact / Feedback form or one of these email addresses:

Creative Commons License

Except where otherwise noted, dominoGuru.com by Chris Toohey is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.