Planning Applications That Work in Both Notes and Web Clients
Unique to designing applications for Lotus Notes and Domino 6 is the fundamental capability to “write once, run anywhere.” The idea is simple enough: You can design an application that will work similarly for both native Notes clients and Web clients. Naturally, this reduces the amount of time required to develop applications that must support both clients. Although previous releases of Notes/Domino supported this feature for many of their design elements (sometimes with mixed capabilities), sophisticated applications often still required additional, specific development for each client supported. With the additional support for mobile clients added in Release 6, the idea of “write once, run anywhere” has become even more difficult to accomplish.
Nevertheless, when designing applications to be accessed by both Notes clients and Web browsers, there are some development standards and best practices (encouraged by Lotus, too, of course) to consider when building applications.
First, the database ACL is not the only way to control access to a database. Although the Basics section of the database ACL lists the access levels for users, groups, and servers; the Advanced section specifies the maximum level of access allowed from the Web. This is set in the Maximum Internet Name and Password field.
Other access control features are not available on the Web, nor are they available to mobile clients. For example, encryption is not supported on the Web or for mobile users. This is not to be confused with implemented SSL, which encrypts the transmission of data to Web clients. The ability to actually encrypt Notes documents is specific to the Notes client. On the other hand, data that has been encrypted for the Notes client is safe from access by mobile clients or Web users.
When designing applications that will be accessed by Web users, graphics play an important role in building an intuitive and easy-to-use interface. However, unlike traditional Notes clients applications, where graphics are stored in the database design (running locally or on a Domino server), Web users must download the graphics in real time to their browsers before they are displayed. This introduces an issue of application performance if the graphics incorporated into the application are large. Nevertheless, you can use Web-specific features such as DHTML and Cascading Style Sheets (CSS) to reduce the file size for Web users and minimize page load times.
 | When using graphics for applications (specifically Web-enabled applications), you should use shared resources to insert graphic images and not paste them directly into the page or form. This can significantly improve performance because these images can then be cached by the Web client for subsequent HTML page requests. In addition, this saves space in the database and eases application maintenance because the image is stored in one central place but can be used throughout the application. |
When designing applications for both Notes clients and Web clients, you must understand the fundamental principle that only back-end classes can be used when you use LotusScript in agents, servlets, and libraries. Therefore, when designing agents, servets, and libraries that can be referenced by both clients (and also mobile clients), avoid referencing front-end classes whenever possible. That way you can use the same code for multiple clients and minimize development time and effort.
One option when developing for multiple clients is to develop a separate, distinct design element (for example, a form or page) for each client type (for example, a Notes client, Web client, or mobile client). This initially gives the developer the most freedom to exploit the capabilities of each client without needing to consider the limitations inherent to each client. Unfortunately, developing separate design elements for each client type makes maintenance more difficult because a modification on one form (for example, changing the field type of graphic resource) requires the same change on another form. Consequently, another option is to design one design element (form or page) and use hide properties, subforms, and so on to make the same design element work for all required client types.
Notes/Domino has merged some of the capabilities previously limited to one client type to work better for multiple client types. JavaScript is now supported by Notes clients as well as Web clients. Therefore, features such as field validation can be implemented in JavaScript, and the same code base can be used to execute them for both clients.
 | Expect to see an exam question regarding the fact that JavaScript can be implemented in both Notes clients and Web clients for local input translation and field validation functions. |
When using the Formula language to implement field validation for Web browsers, the form must be submitted so that the server can evaluate the formula. Then the results are served back to the Web client (a message is displayed to the user that the field validation failed and the user must navigate back to the prior form to correct the input field). This requires additional HTML requests to the server and degrades performance. Therefore, utilizing local JavaScript can improve performance and usability.
Keep in mind that although most fields work similarly for both Web clients and Notes clients, not all the field features are supported by both clients. For example, the Web clients cannot use dialog boxes, Calendar/Time controls, and so on. Therefore, if you attempt to design the fields for access by both client types, limit the field types to check boxes, dialog lists, radio buttons, and so on.
Another consideration when designing for Web clients is setting the database property for Web Access: Use JavaScript When Generating Pages. If this property has not been enabled, only the first button on the form is recognized and is automatically treated as a submit button. This result often isn't the one you want. When this button is enabled, all the buttons, actions, and hot spots are displayed, even if one of the buttons, actions, or hot spots uses @Commands that are not supported by Web clients.
When designing for Web clients, there are reserved fields and reserved form names that provide Web-specific functionality. The $$Return field allows you to return HTML to the user (typically a message or a URL to another Web page). Reserved forms make common Web functions easier to design and maintain. Table 13.1 outlines some of the reserved forms available for Web clients.
| Form Name | Description |
|---|---|
| $$ReturnAuthenticationFailure | Displays an error message to Web users when there is an authentication failure |
| $$ReturnAuthorizationFailure | Displays an error message to Web users when users attempt to perform an unauthorized command (for example, as determined by the ACL) |
| $$ReturnGeneralError | Displays a message to users when an error has occurred (rather than the default error message) |
| $$ReturnDocumentDeleted | Displays a message to users after a document has been deleted |
Chapter 2 (“Database Management”) covers database properties and their effects on Notes and Web clients. Nevertheless, you should be aware of a few of the properties that are specific only to Web applications and the effect they have on Web applications.
To examine the database properties, right-click on the database bookmark title and select Database, Properties from the drop-down menu. If the database is currently open, you can also click on the Properties Box icon from either the SmartIcon bar or the Properties Box button located by the Preview buttons in the top-right corner of the window.
The Database properties box has seven tabs (see Figure 13.2):
Basics
Information
Print
Design
Launch
Full-Text Indexing
Advanced
Figure 13.2. Domino Database properties dialog box.
Some of the properties available on the Basics tab involved in the creation of Web applications are located in the Web Access area of the tab; they are described as follows:
Use JavaScript when Generating Pages— Allows the use of additional @Commands and multiple buttons on forms, and converts many @Commands to JavaScript (check box field type).
Require SSL Connection— Forces Web clients to use SSL (Secure Sockets Layer) to log in (check box field type).
Don't Allow URL Open— Restricts Web users from entering URL commands such as ?openDatabase to open the database and specific design elements.
On the Launch tab, the following setting affects the Web application:
When Opened in Browser— Determines the default design elements to open when the database is opened by a Web client (dropdown field type).
The default launch options for Web clients are
Use Notes Launch Option
Open About Database Document
Open Designated Frameset
Open Designated Page
Open Designated Navigator in Its Own Window
Launch First doclink in About Database
Launch Designated Doclink
Launch First Document in View
In addition to database-specific Web features, several form design features are not applicable to Web applications and are, consequently, not available to Web clients. To gain access to these design elements, open an existing form (or create a new form) and open the Form properties box.
To examine the form properties, open the Form design element and click on the Properties box icon from either the SmartIcon bar or the Properties Box button located by the Preview buttons in the top-right corner of the window (see Figure 13.3).
Figure 13.3. Form properties dialog box.
The Form properties box has seven tabs:
Basics
Defaults
Launch
Form Background
Header
Printing
Security
Some of the form properties involved in the creation of Web and Notes applications are provided in the lists that follow.
Only one design feature specific to the Web is available on the Basics tab. That feature, Render Pass Through HTML In Notes, is in the Options area of the tab.
The design features specific to the Web available on the defaults tab are
On Web Access: Generate HTML for all fields— This setting results in HTML being generated for hidden fields (whose type is still hidden). Otherwise, hidden fields are understood by the server but never served to the client as HTML; therefore, they are not accessible by the client.
On Web Access: Active Link— Determines the color of font text to display for active links.
On Web Access: Unvisited Link— Determines the color of font text to display for unvisited links.
On Web Access: Visited Link— Determines the color of font text to display for visited links.
Many of the design elements now have an <HTML> tab on their respective properties boxes. This tab enables developers to specify attributes specific to those design elements (such as ID, Style, Title, Other, Access Name [for fields]), or that may be common across objects, such as Class with Cascading Style Sheets. Nevertheless, the properties specified here further assist developers who are using the HTML 4.0 standard to design applications that control the attributes of the Web objects. Using HTML with design elements is covered in more detail in Chapters 14 (“Design Elements”) and Chapter 16 (“Programming”).