Working with Special Forms

Several types of special forms can be created for specific purposes. You can use a form to create database and user profile documents, and you can create Search forms and Results forms. New to Designer 6 are forms that hide documents and forms that print contacts.

NOTE

R4 had a number of reserved form names for use in Web applications. For the most part, these are no longer necessary with the introduction of pages. Each reserved form name began with $$ and was used to present Domino views and navigators. Here is a list: $$ViewTemplateDefault , $$NavigatorTemplateDefault , $$ViewTemplate for viewname , and $$NavigatorTemplate for navigatorname .

Working with Profile Documents

Profile documents are created from a document-type form. Documents created with a profile form have no presence in views and aren't included in the total document count. Profile documents can be global to the database, or they can be specific to individual users of the database. Profile documents are a great place to store information that will be referenced elsewhere in the database. For example, you might store the replica ID of a database that is used for lookups. Of course, you could also place a replica ID in a shared field, but that would require a database designer to modify the field contents if the lookup database changes. When it's stored in a profile document, users who can create the document can modify the field storing the replica ID. You can also store user-specific information in a profile document that stores default settings for fields, or criteria for email notification when documents are created or modified in the database.

The difference between the two types of profile documents isn't determined by a setting on the form, but in the way the document is created from the form. If you are creating a database profile document, you call it with the following formula:

(@Command([EditProfile]; profileform )

To create a user-specific profile document, use the following formula:

(@Command([EditProfile]; profileform; username )

If you are creating a database profile document, you must have at least Author access.

It is usually a good idea to limit access to a global profile document. You can do so through the use of a role. You should also keep the profile document off the Create menu, hide it by enclosing the name in parentheses, and provide access to it only through an agent.

The following code is from a shared agent set to run manually from the Actions menu and to run once (@Commands can be used):

@If(@Contains(@UserRoles; "Profile"); @Do(@Command([EditProfile]; "GPF")) ; @Return(@Do(@Prompt([OK]; "Warning!"; "You are not authorized to edit this database 's profile!")) ) )

This agent is called Set Global Profile and is in the sample database for this chapter. This agent checks the user's access privilege; if the user has the Profile role, it permits them to edit the profile document.

When you've created the profile document, you'll need to access the data stored in its fields. You can read the data using @GetProfileField and write data using @SetProfileField . For example, say you've stored a list of categories for a keyword field in a global profile document. You could read it into a keyword field using the following formula:

@GetProfileField("GPF"; "cCategories")

If you wanted to retrieve values from a user-specific profile document, you would simply add the username as an argument, as in the following example:

@GetProfileField("GPF"; "cCategories"; username )

All in all, profile documents are a very welcome addition to the Domino Designer toolkit. You can find a use for a profile document in almost any database you create.

Customizing Search and Result Forms

The Catalog (6) template (catalog.ntf) installed with the Domino server contains several forms used to search and display search results, and these can be customized. There are four forms: Search Form, SearchResults, ResultEntry, and DetailedResultEntry. These forms are functional as is, but you can add corporate logos, instructions, and whatever else you need to them. These forms are designed to search the database catalog and file system, but you can also customize them to search the Web.

Extensive documentation in the Designer Help database describes how to customize these search forms. You can find this information in the document titled "Customizing Search Forms." When you have modified the search forms, you can simply add them to the Domain Catalog.

Switching Forms

Sometimes an application requires the information collected in a document to be displayed in a form other than the one that collected the information. A form can be thought of as a window into a document; different forms can display different information in the document. For example, you may have a workflow database for purchasing. Once all the approvals are complete, you may want to display only information related to the items being purchased to the purchasing department. To accomplish this, you can create a special Purchase Order form to display the documents. Make sure that the special form doesn't appear in the Create menu if you don't want people creating new documents from it.

You can switch forms from the menu by choosing View, Switch Forms when a document is open . This isn't very practical because it requires extra steps. A much better solution is to use a view's form formula. You would then create a Purchase Order view and change the form formula to evaluate to the name or alias of your Purchase Order form. This is better because the documents are always displayed in the Purchase Order form from this view.

The form formula also controls which form is used to create new documents from the view. Regardless of which form you select to create a new document, the form formula forces the use of the form to which it evaluates . You can avoid this by adding a test for new documents at the beginning of the form formula, using @IsNewDoc .