Creating, Modifying, Troubleshooting Forms for Web Clients

Approximately 80% of a typical Domino application will work well on both the Notes and Web platform. Some tweaking may be required for elements that do not translate to the Web, are not suitable for both clients, or don't work well in Notes. This tweaking can be accomplished by using hide-when formulas or subforms. @BrowserInfo is a function that not only indicates a Notes client but can also differentiate between the different browsers. Using the BrowserType property, Notes clients return the value Notes and browsers return Microsoft, Netscape, Compatible (with Netscape, including Notes Navigator 5.0), or Unknown.

Not all @Functions or @Commands work in Web clients. In preparing for the exam, be aware of which ones do (such as @BrowserInfo), and just as importantly, which ones don't (such as @PickList). @Functions and @Commands are discussed in detail in Chapter 16, “Exam 612—Programming.”

Even though Domino is designed to work in a mixed-client environment, there may be times when it is more viable and/or just plain easier to create two separate forms, one for each client. Worrying about and coding for the different idiosyncrasies of each client is thus eliminated even though more maintenance may be required. Maintenance chores could also be lessened if you were to assign the same alias name to each form, then hide one from Notes and the other from the Web. In this way code would not have to question the type of client—just access the alias and the proper form will open to the correct client.