This topic presents several important design and implementation considerations.
Back Button
The power of FlashConnect dynamic applications flows from the fact that there is a D3 server process synchronized with the browser client tracking the state of the application.
Most browsers have a Back button that allows a user to view previously displayed pages. This can cause problems since the default behavior of the FlashConnect dynamic application is to hide the answers to previously asked questions from the application and to redisplay the last page output by the application when the Back button is clicked.
To allow the use of the Back button, the application design or modify the application using an event-driven flow (rather that using a top-down or state-driven flow) and add the w3InputNumberTrackingOff option to calls made to w3Input.
Reloading Forms
If an application consumes D3 resources, such as item locks, and the Web page is reloaded using the Browser Reload button, the application may attempt to consume the resources again, possibly resulting with an undesirable outcome. This is most likely to occur when the resources are consumed on the first page of the application, where a reload establishes a new connection, rather than a subsequent page where the existing connection is reused. To avoid this problem, do not consume resources until the entire transaction can be completed.
Using Frames
A FlashConnect session can be used from several frames at a time. Concurrent requests are queued, then passed to the application as the application becomes available.
A common use of frames is to have one or more menu frames and an application frame. When a user finishes running an application, the next area of interest is usually selected from the menu frames. Care must be taken to properly clean up the underlying persistent application.
For more information, refer to the FlashConnect Programmer’s Online Reference.
Standard Look and Feel
FlashConnect provides the ability to create a consistent Web site design by utilizing the same links and buttons throughout the site. Creating a site with a consistent, professional design facilitates site navigation.
Using the Init, Header and Footer Subroutines
The key to standardizing FlashConnect applications is using the w3HtmlInit(), w3HtmlHeader() and w3HtmlFooter() subroutines.
A call to w3HtmlInit() passes the application name (W3Admin in this example). This name is used to generate the name of the headfoot.htm item (w3admin.headfoot.htm in this example) which is used by the w3HtmlHeader() and w3HtmlFooter() subroutines to output the style sheet for each page. By using the same application name for each page in the application, the entire application can utilize the same navigation features, such as button bars and search buttons. Thus, making one change updates the style for all pages in the application. See w3HtmlHeader() in the FlashConnect Programmer’s Online Reference for more information about the headfoot.htm layout.
See the D3 item www,w3html, w3admin.headfoot.htm to view the format of a sample headfoot.htm file.
Customizing the FlashConnect Logon Screen
When a user logs on to a dynamic application, they can be prompted for their user name and password. The prompts User Name and Password are contained in the D3 dm,messages, file and may be modified as necessary to fit the application requirements. To customize the logon screen, modify the w3LogonScreen program.
Using Secure Socket Layers
Secure Socket Layers (SSL) are supported for both anonymous and secured applications. To indicate that the SSL protocol should be used for a form or a link, specify the w3HtmlFormSSL flag for the call to w3Action, w3HtmlFormBeg, or w3HtmlAnchorBeg.
Secure Socket Layers can only be used by a secure Web server that has a certificate from a valid source. See your Web Administrator for more information.
To present the logon screen using SSL, the application’s Option attribute in the w3Apps file must contain an "s".
See Also