O4W Configuration

O4W is built upon OpenInsight's OECGI processing, and thus the OpenInsight OECGI configuration settings may need to be modified to allow O4W requests. Please see the “Server Configuration” section in the OECGI4.EXE Quick Start Guide for more information.

The CFG_O4W record in the O4WCONFIG table contains configuration settings for O4W. This record is maintained by the repository functions; therefore, it can be customized on a per-application basis, and an application specific configuration record will have a key of <appname>*CFG_O4W (for example, “EXAMPLES*CFG_O4W”). While the O4W Configuration Maintenance routine is designed to allow you to customize the settings in this record, there are some advanced configuration settings that are not available through the web interface for the current release. If required, these settings can be manually maintained via the OpenInsight editor.

These advanced customized fields include:

Field 10: You can modify your jQuery Themes by changing the theme name on this field. O4W comes configured with the flick theme. You can change this theme to a jQuery theme such as smoothness or ui-darkness.

Field 21: The path and name of the template to use by default when a mobile device is accessing O4W (Note that the mobile device must still access an O4W page that sets a cookie named “o4wMobile” to 1 so that O4W can identifier a mobile request);

Field 38: The name of an existing O4W Form to use as the “template” during dynamic O4W Form generation (If field 35 is set to ‘1’, then both dynamic reports and dynamic forms can be generated by O4W. For a dynamic report, users can specify the name of an existing OpenInsight form, and O4W will convert the form “on the fly” into an O4W Form. The O4W Form named in this field will be used to define the layout and various settings of the dynamically-generated form);

Field 40: An @VM-delimited list of browser identifiers

Field 41: An associated @VM-delimited list of names for each browser identifier

Field 42: An associated @VM-delimited list of the minimum supported version for each browser

Field 43: The text of any message to display on any browser that is below the minimum supported version

Field 44: The type of message to display (0=banner at top of browser, 1=popup window, 2 = both)

Field 45: A configuration-generated script that can be embedded in the O4W results to display the message

Field 50: The time (in milliseconds) to delay before setting the focus to a control programmatically

Field 55: The maximum number of engines to use when constructing an O4W form for display (If set to a number greater than 0, when an O4W Form is generated, only the first tab is generated initially; additional ‘background’ requests are issued to populate any additional tabs. Up to the specified number of engines will be used to populate these tabs. This provides the appearance of more responsive forms. Note that it is also possible to specify “-1” for this value; in this case, a new tab will be populated ONLY when it is clicked on by the user)

Users may also find that they wish to create their own version of INET_FINALIZE, the 'wrapup' routine, to perform any post-processing on the HTML responses. One common use for an INET_FINALIZE routine is to ensure that, for any secure requests (those that begin with "https://"), any returned html contains only https:// references (mixing http:// and https:// references in the returned document may generate a warning or error on the browser). One solution when working in an "https://" environment is to ensure that any references in O4W templates or code properly use "https://" as well; another approach is to have a customized INET_FINALIZE with the following code:

* make sure we're HTTPS compliant

if request<HTTP_REFERER$>[1,8] _eqc "HTTPS://" then

  swap "http://" with "https://" in html

  Swap ":433/" With "/" In html

End

(Note that it is suggested that you always create a custom, differently-named routine - perhaps initially copied from the provided INET_FINALIZE routine - and replace the INET_FINALIZE entry in the CFG_INET record with the name of the new routine, rather than just changing the provided INET_FINALIZE routine, to avoid the possibility of your custom code being overwritten by updated system routines)