Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

I've witnessed debates -- sometimes fairly heated -- about the proper way to store the "business logic" relating to a form. I wanted to introduce the subject here because it's always fun to watch a good fight.

"Traditional" development for the Notes client generally entails storing the logic that relates to a specific field, along with the field. I refer to the default (or value) formula, input translation, input validation, Entering, Exiting and Onchange events. Some of these events can be written in JavaScript also, making them applicable to Domino web applications. (Technically, default, translation and validation formulas can also be used for web apps, but the user experience with input translation formulas, at least, is not up to modern standards of web design).

However, those who are versed in software engineering principles, often want to apply the MVC pattern to designing for Notes; and this involves keeping the logic of managing the data and extracting meaning from it, separate from the design of the user experience. The ideal here is that whether the data are accessed through a form, a view, or an agent, the same code handles the transaction, so when there is a change there's only one place that needs to be updated.

The obvious way to apply MVC to a Notes client application is through a script library that represents the data on a form. You might have a class whose constructor accepts a document as argument, and performs manipulations on that document (perhaps another class would handle locating and organizing documents that use that form). Rather than having an input validation formula on a form, you would have methods to update the values of individual fields. This class would perform the input translation and also update related fields (where in the traditional model you might use a computed field formula), and would refuse to perform the update if this would result in invalid data (instead of using a validation formula). So the logic on the form would be reduced to calling methods of these classes.

This has some obvious advantages when you write agents, for instance, because it becomes simpler to make sure your computed fields get updated when you change another field that affects them.

However, it also violates the paradigm of Notes as a rapid application development platform. By adding layers of code, you reduce the flexibility of your application and the ease of copying and modifying applications to suit yourself. With the traditional techniques, if you copy a form, you are also copying the logic associated with that form, so it's quite easy to create a similar form in another database, or to create a slight variant of an existing form, without having to find and copy and customize additional design elements. If you copy a field, you are also getting the formulas and events associated with that field (which you might not always want, but it's easier and less error-prone to remove or modify them by clicking on the field, than to locate the appropriate code in a script library and copy that into a new script library). In addition, of course, you often have to work quite hard to effect the business logic in the Notes client from a script. For instance, there's no way for script code to directly supply values for a keyword list -- obviously the list of valid values is part of the business logic, and you would want to manage that in your model code, not on the form.

Likewise, a view accesses the items of the documents directly via formulas, and may transform those values for display. Under MVC, the code that calculates what appears in the columns should not be part of the same design element that controls the column widths and fonts.

This sort of thing is a little easier to apply if you're designing a web application, where you can just not use a form if you choose, but instead write agents to generate the HTML for whatever web page you wanted to put out, receive and process the post data, etcetera. If you do this it begs the question why you're using Domino in the first place. If you bypass everything Notes does to help you manage the data, you might as well write your application using a development environment that allows you total control at every step of the process. I feel that if you're fighting against the development environment to make it do what you want, or bypassing major parts of the supplied functionality to write your own versions of things that are already supported, something is probably wrong with your approach.

Using MVC in Notes/Domino also violates another key advantage of Notes -- the relatively low barriers to doing Notes development. If you create an application that software engineers will love, the drawback is that only software engineers will be able to maintain and extend it. Many Notes applications were developed by people without formal IT training -- often by taking the supplied templates and adding fields and views. This is both a blessing and a curse. While I'm certainly among those who complain loudly about the boneheaded things novice developers do that wreck performance or result in a less than optimal UI, it's well to remember that an application doesn't have to be perfect to be useful, or to be a lot better than whatever process it replaced.

I think the ability for the department secretary to create an application for the department after reading some book, is far more important to the success of Notes than adhering to a strict software engineering discipline. I think we are better advised to bend our efforts to reducing the amount of trouble novice developers can get into, by providing better education, and better free tools for developers and administrators to apply to applications to discover problems and assist in correcting them.

Andre Guirard | 29 January 2008 08:00:00 AM ET | Plymouth, MN, USA | Comments (11)

Search this blog 


    About IBM Privacy Contact