Anyone familiar with application development probably understands the importance of naming design elements (such as forms, views, and pages) and objects (such as fields or text paragraphs). Naming conventions not only affect users but also impact code development and maintenance for an application developer. Careful consideration should be given when naming both design elements and objects.
All of the design elements, as discussed later in this chapter, must have a primary element name and optionally an alias name. The primary name, in most cases, will appear in the Notes application and will be visible to the application end-users. Although most design elements have an alias, some do not, such as script libraries and shared fields.
For example, forms are used to capture and display database information. By default, when a form is created and saved, the form name is automatically added to the Create menu in the application. This allows the user to add data to the database via the application menu options. Let's say, for instance, you have an application used to track customer service requests. Naming the form "Service Request," as opposed to "Form A," would be more meaningful and better understood from the user's perspective. To submit a request, the user would simply select the Create > Service Request menu options (which makes more sense than Create > Form A).
In addition to the primary element name, you can optionally specify an alias name. The alias is a synonym used to reference the same design element. Best practices suggest that you should always provide and reference the alias name when developing a Notes database application. This provides greater flexibility to accommodate changes without impacting code, views, agents, or other aspects of the application. Unlike the primary name, the alias name typically does not appear to the users in the client.
Using the same example of a Service Request, the alias name could be "SR." This alias name would be referenced in other Notes database design elements. For example, let's say the service request application (or database) has several forms, and you want a view that only displays service requests. To create this view, a selection formula would be added to the view to display only service request documents. Now, the formula could reference the primary name, "Service Request," or "SR" if an alias has been specified. If an alias has been provided, the selection formula for the view must reference the alias name. Using the alias name is the recommended development approach.
The alias name for a form is stored in the document in the Form variable. By storing the alias name, the visual name can be changed without affecting the application. However, be aware that adding an alias after the application has been implemented will most likely affect the display of information in the database. For this reason, it's a good idea to implement an alias name at the start of the project.
As an application developer, you will find that design changes are common when building and supporting applications. So, if the customer suddenly decides the form name should be changed from "Service Request" to "Request For Service," you could accommodate the change with minimal impact to the overall application design, provided that the code referenced the alias name. Otherwise, changing the name to "Request For Service" affects not only the form name but also the view formula and any other design element where the primary name was referenced.
Always provide a primary and alias name for a design element. To specify the alias name, type the primary name, a vertical bar "|", and then the alias name (e.g., Request For Service | RFS).
The first time you save a design element, you will be prompted to specify a design element name (see Figure 4.2). With the exception of views (which have a dedicated property for the alias), you should specify a primary name, a vertical bar "|" separator, and then the alias name.
Figure 4.2. How to specify the primary and alias name when saving a design element
Be aware that you can save multiple design elements with the same primary and alias name. Although some advanced application designs may implement multiple forms with the same name, in general you should ensure that the primary and alias names are unique and have not already been used in the database design. This will eliminate potential problems. One way to address this issue is to preface the alias name with an abbreviation designating the element type. So the Service Request form could have an alias of formSR, and the Service Request view could have an alias of viewSR.
Working with Forms
An Introduction to the Lotus Domino Tool Suite
Getting Started with Designer
Navigating the Domino Designer Workspace
Domino Design Elements
An Introduction to Formula Language
An Introduction to LotusScript
Fundamentals of a Notes Application
Reference Library Applications
Design Enhancements Using LotusScript
Design Enhancements Using Formula Language
Miscellaneous Enhancements and Tips for Domino Databases
Application Deployment and Maintenance
Appendix A. Online Project Files and Sample Applications
Appendix B. IBM® Lotus® Notes® and Domino®Whats Next?