Converting Forms to HTML
Forms can easily be saved for use by a Web environment. The Run Form Web on the developer tool bar is useful to view what the form would look like in a Web browser (the traffic light with the globe behind it runs the form in a Web browser). It is also a convenient way to code and debug a form that is destine for Web access.
When deployed, the form runtime will actually run on the application server and interact with an applet that will actually display the form on the Web browser. Figure 5.69 illustrates that the applet will be downloaded to the Web browser but that the form runtime will actually run on the Oracle9iAS server.
Figure 5.69. Web Forms runtime environment.
To run Forms Developer applications on the Web, you must install two components: the Forms Client and the Forms Server from the Forms Developer v6.0 Installation Media.
The Forms Client is a Java applet downloaded to a user's Web browser when a Forms Developer application is being accessed. This applet maintains a login and serves as an interface between Forms Server software installed and the Web browser.
These applications have their own URLs that access the Forms Client applet and begin the interaction with the Forms Server. The Forms Server is imbedded in the Oracle9iAS, see Figure 8.9 in Chapter 8, “Building Web Sites with Oracle9i,” and shares connection services with the other parts of Oracle9iAS. Oracle9iAS with the Forms Server installed manages the interaction between end users and the Forms Server. The Forms Client receives bundles of interface commands from the Forms Server and translates them (in sets) into interface objects for the end user. Some interface events handled by the Forms Server Runtime Engine in a client/server implementation, such as typing characters in a text field or moving around a dialog box, occur only on the Forms Client in the Web implementation, with no interaction with the Forms Server Runtime Engine.
When the user gives the URL, the HTML pages are downloaded to the Web browser. The forms listener is a Java servlet and the client will download, if necessary, the Java archive file containing the Forms applet. The forms applet is instantiated and the parameters from the HTML page are used to determine the forms application to run. The forms applet then sends a request to the forms listener. The forms listener contacts the forms runtime engine and connects to a forms services runtime process. The forms listener passes any forms command-line parameters (such as database SID, user ID, password, and so on) as well as any user-defined form builder parameters to the forms services runtime process. A connection is established by the forms listener with the forms runtime engine and the connection information is sent to the forms applet. From this point on, the forms applet directly talks to the runtime process. When control goes to the client, the forms runtime creates a timer. The timer value can be set by FORMSxx_ TIMER and it defaults to 15 minutes. If the timer expires, the middle tier process knows that nothing is received from the client for that duration of time and the client no longer exists and can be terminated.
TIP
If using Forms 6i earlier than Patchset4, the default port for Forms server listener is 9000. However, the forms listener servlet—a Java servlet introduced in Forms6i/patchset4—removes this limitation so that none of the ports need to be exposed at the firewall other than the Web server ports.
Web-Based Forms Tuning Tips
Create a simple form that prompts the user for login information. This form will be small and will initiate all the necessary transactions between the form's runtime and the browser applet. It will also be small in size and will load quickly on the apps server. Then do a new_form from inside this form to start the first form for the user to see. A call_form would take more memory and the original form will stay active but not used. A new_form starts the new form and exits the exiting form.
Make the screen simple, use less graphics, and try to avoid any kind of a timer. This will be covered in greater depth in the following section, however the fewer graphics there are, the faster the form will load into the browser. Also, the use of PL/SQL timers can cause quite a bit of network traffic, something to try to avoid with Web-based applications.
Web-Based Forms Coding Tips
When developing forms the font size will probably be different from that used by the client web browser. Try to use 9-point pitch. Chapter 2 of the forms online documentation discusses acceptable fonts. Use visual attributes to set the button colors as this is also not handled by the client Web browser.
Design your forms to have a Web look about them. Avoid using tool bars. Set up buttons for the various forms states such as next-record, previous-record, block navigation, and Query mode. Avoid using multiple MDI type windows. Try to use tabs instead.
Some triggers will not fire at all and some triggers will create network havoc if used. Be careful with the WHEN-MOUSE-type triggers; they may not work as expected and they may create quite a bit of network traffic. For example, try to avoid using KEY-NEXT-ITEM triggers as they fire as the mouse enters and leaves a field. If you use :SYSTEM.MOUSE_BUTTON_ SHIFT_STATE or :SYSTEM.MOUSE_BUTTON_PRESSED, the values contained in these events will be different from windows based applications to that of the Web. For example, the MOUSE_BUTTON_PRESSED in a windows environment will have a 1 for the left mouse button and a 2 for the right mouse button. In a Web environment, it is either a 1 or nothing at all. Use :SYSTEM.MOUSE_BUTTON_MODIFIERS and check for the values you are looking for such as “Hyper+,” “Caps Lock+,” “Alt+,” and so on.
Remember that the form is actually running on the application server so any HOST command such as to notepad will occur on the application server, not the client machine.
Keymappings will be different from your system and from Web browser to Web browser as well. The forms runtime will use FMRWEB.RES found in <Oracle_Home>FORMS60 directory by default. You might want to use FMRPCWEB.RES file to give a better key mapping from a PC Web browser environment. This file is found in the same directory. You can copy one to the default name or use a runtime parameter to use the different key-mapping file.
Some helpful forms level parameters to set are
LookAndFeel=oracle (will use the default Oracle color scheme)
Usesdi=yes (will turn off the Multiple Document Interface)
SeparateFrame=false (runs the form in the current browser window)
SplashScreen=<your logo.gif> (gives the user the appearance that the form is loading immediately)