When creating the About Database Document, we made sure certain questions were answered for each database:

• What is this database?
• Who created this database?
• Who will maintain this database?
• How do I use this database?
• Who manages this database?

Likewise, we wanted to make sure the Using Database Document answered a certain series of questions:

• What types of data are in this database?
• What forms are in this database?
• How do I create new documents?
• What views are in this database?

What are other design components that can help with these standards?
In my earlier article, I demonstrated how to create a standard subform to be used at the top of your forms. In looking at the lists above, you can probably see several places where it would possible to create design objects like views, folders and navigators that can be "pre-built" with the correct style and then modified to fit the need of a specific application. To complete this article, I'd like to define just one of those objects: a subform to handle the bottom of your Notes forms. Here we go.

The standard form footer
Many Notes developers like the bottom of their form to display information about the current document. Information like the date that a document was created, the date of the last edit and the document's author is helpful to the users of the application and support personnel alike.

To get started, let's create a subform and call it "StdFrmFooter". We'll place four fields and some static text on the subform as shown in Figure A.

FIGURE A


Our StdFrmFooter subform can look like this. Roll over picture for a larger image.

In order to keep this subform simple, we'll only place four fields on it. And in order to keep the subform completely re-usable, we should use the standard Notes fields $UpdatedBy and $Revisions to retrieve most of the data. $UpdatedBy contains a list of the people who have edited this document for forms that are not anonymous. $Revisions is a list of datetime values that record when a document has been edited.

Although Notes will sometimes automatically purge some of the entries in these fields, for our purposes it's fair to assume that the last editor and edit date will always be available if these fields are there. An example of the fields is shown in Figure B.

FIGURE B


$Revisions and $UpdatedBy are almost universally available in all Notes documents. Roll over picture for a larger image.

Those give us two of our four fields; what about the other two? Using the @Created function, we can always know when a document was created.

What about the creator of a document though? @Author won't always work, so in order to accommodate anonymous forms and to be sure we know who created a document, we'll need to save a field on each document. In this example, I'm using a field called Ftr_CreatedBy. Because we can't interfere with workflow applications that use Author fields to control security and we need to determine whether a form is anonymous, the Ftr_CreatedBy field needs to be a Computed Text field. Finally, in order to keep everything on the form looking tidy, we'll use "Hide when" formulas to suppress the display of unavailable information.