![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Designing a corporate data management system can be a complicated and time-consuming process. This is especially true when the type of information users must enter into the system varies from one document to the next. An example of this is an asset tracking system, where the type of asset (for instance, software) requires specific fields (such as revision number and operating system) that only apply to that asset type. Keeping track of which fields apply to which types, and making sure that only the required fields appear for the user to fill in, can be a real challenge.
In this tip, we present a way to meet this challenge, using a method that is both logical and easy to maintain. We do this by organizing Domino Designer data elements into a simple three-level hierarchy. These design elements include forms and subforms. To illustrate their use, we will describe a sample asset information system. We chose this application because corporate assets are often numerous, varied, and difficult to track.
In our hypothetical company, the asset categories are hardware, software, Notes ID, and so on. Each category has its own properties and detail information. Customizing each category could quickly become a very complicated process, requiring numerous forms. To help simplify this, we need to analyze each category, and determine (1) what information is shared by one or more categories, and (2) what information is unique to each one. Sorting out the common data for the categories will help us build our asset form later on.
The asset form contains three types of fields:
- Common fields appear on all types of asset forms. Examples of common fields include Asset Type, Asset ID, Department, and Original Cost.
- Category fields are specific to particular categories. For example, Serial Number applies to the category Hardware, Platform applies to the category Software, and so on.
- Unique fields contain information specific to a particular asset type. For instance, the fields CPU, Memory, and Hard Disk apply only to the Desktop PC asset type.
Figure 1 shows a typical asset document created with our sample asset form:
Figure 1. Asset form
As Figure 1 shows, our asset document includes common fields such as Asset Site and Asset ID, to contain information that applies to all types of assets. The form also contains category fields that apply to the category in which this asset falls, as well as fields unique to this specific asset type. (Later in this tip, we explain how we ensure that the right category fields and unique fields appear for the right asset types.)
After we've assigned all asset fields into these three categories, we see that they present the framework for a simple classification scheme, with common fields at the top, category fields in the middle, and unique fields at the bottom. As we go from the high-level common fields and dive down through the category and unique fields, we find data of increasing specificity. For example, let's consider a particular type of asset. In the common Asset Type field, we enter the value Desktop PC. The value in the Asset Type field identifies this asset as belonging to the category Hardware, so we need to fill in the category field Serial Number. We then need to complete the fields unique to this asset type.
We can use this classification scheme to form the structure of our asset form, one that is both extensible and flexible to adapt to the changing requirements of our asset management system.
Defining the asset form and hierarchy subform
The first thing we do to implement our asset management system is to create a form called AssetInformation. We then use computed subforms to categorize the asset. This means that when the Asset Type defines the asset as belonging to a particular category (for example, Software), the computed subform displays the category fields appropriate for that category (see figure 2):
Figure 2. Computed subform
The use of computed subforms creates a "parent/child" relationship between the asset type (the "parent") and the appropriate category and unique fields that should be displayed for that asset (the "children"). To ensure that the right fields display for the selected asset type, we include a key pointer in the subforms. This pointer identifies the subform as a "child" of a particular asset type, so that when that type is chosen, this subform appears.
We also need to "synchronize" all code changes that occur within the parent asset and its children subforms. This synchronization is necessary so that parent and children "know" about any changes made to each other, and thus all children fields continue to display for the correct assets. To do this, we need to create an agent that contains the following code:
Sub synchronizeChildren(sourceDoc As NotesDocument,
db As NotesDatabase, flag As String, msg As String,
signature As String, changeDate As String)
Dim child As NotesDocument
Dim dc As NotesDocumentCollection
Dim searchView As NotesView
Dim assetID As String
Dim historyItem As NotesItem
Dim docHistory As NotesDocument
assetID = sourceDoc.AssetID(0)
Set searchView = db.GetView("($AssetListByParentIDSYN)")
'find current asset's children and put them in dc
Set dc = searchView.GetAllDocumentsByKey(assetID)
Set child = dc.GetFirstDocument
Do While Not child Is Nothing
If msg <> "" Then
Set historyItem = child.GetFirstItem("History")
historyItem.AppendToTextList msg
End If
child.ComputeWithForm False, True
child.Save True, False
'recursion
synchronizeChildren child, db, flag, msg, signature,
_changeDate
Set child = dc.GetNextDocument(child)
Loop
End Sub
|
Setting the relationship of the design elements
Now we need to connect all these data elements in a way that presents a single, unified data entry interface to users. As we mentioned previously, our asset application uses computed subforms to contain the category fields and unique fields. Certain fields in the asset form, especially common fields, call up an associated subform. For instance, the Asset Type field points to the AssetCategory subform, as shown in figure 2.
We can also connect the main form and subforms through configuration information, as shown in figure 3:
Figure 3. Configuring subforms
For child asset elements in our sample application, the key point ParentID will link to the parent asset form. These child elements can then be displayed via an embedded view (see figure 1).
One final note: Be sure to check the validity of all fields before you submit. (Validity checking code is located in the subform.) Also, set the check hooks in the main form. You must update child assets while updating a parent asset. And as always, be sure to keep a backup document.
- See the developerWorks: Lotus article, "New features in Lotus Notes and Domino Designer 7.0," for a description of new features introduced in the Lotus Notes and Domino Designer 7.0 clients.
- The article "The History of Notes and Domino" provides a good basic background of Lotus Notes and Domino features.
- And for a look at new features that were introduced in Lotus Notes/Domino 6.5, see the article, "New features in Notes/Domino 6.5."
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
