<!-- $Revision: 64296 $ -->
<client-app version="$Revision: 64296 $">
<!-- =================================================================== -->
<!-- Client Classpath ( Customer Code ). -->
<!-- =================================================================== -->
<client-classpath>
<!-- Archives and directories included in the client-classpath may be -->
<!-- specified with paths or URLs. Where a path may be converted to a -->
<!-- file reference, up-to-date checks will be performed as resources -->
<!-- are returned. For all URLs and for paths that can not be -->
<!-- converted to a file reference (for instance if deployed in a WAR -->
<!-- file), no up-to-date checks will be performed. -->
<!-- -->
<!-- About paths: -->
<!-- There are two methods used to resolve the specified paths. The -->
<!-- first method is ServletContext.getRealPath(). If this method -->
<!-- returns null, then ServletContext.getResource() is used to -->
<!-- resolve the path. Therefore paths specified must conform to the -->
<!-- specification for the two ServletContext methods. See the -->
<!-- ServletContext javadocs for more information. -->
<pre-loaded-in-applet-def>
<!-- Pre-loaded archives are archives that will be written into -->
<!-- the applet definition tag directly. These archives are served -->
<!-- to the client in their entirety, not as individual -->
<!-- files. Only "archive" elements may be pre-loaded in the -->
<!-- applet definition. All "archive" elements that are included -->
<!-- in this section must contain the "name" attribute and that -->
<!-- attribute value must be unique across archives. -->
<!-- -->
<!-- Pre-loaded archives also support pack200-gzip files. User -->
<!-- can specify such files using a 'pack200Path' or 'pack200Url' -->
<!-- attribute. You only need to specify a path or a URL. If you -->
<!-- specify both, the path will take the precedence. -->
<!-- The same rule applies to 'pack200Path' and 'pack200Url' -->
<!-- -->
<!-- Example entry: -->
<!-- -->
<!-- <archive name="MyLibrary.jar" -->
<!-- path="/WEB-INF/client/lib/MyLib.jar" -->
<!-- pack200Path="/WEB-INF/client/lib/MyLib.jar.pack.gz" /> -->
</pre-loaded-in-applet-def>
<!-- Classpath items that are not pre-loaded can be archives or -->
<!-- directories. Unlike pre-loaded archives, these entries are searched -->
<!-- for individual files that are served one at a time rather than as -->
<!-- entire archives. For example, a jar file with 10 MCOs that is -->
<!-- pre-loaded will be pulled down by the client as a single jar file, -->
<!-- but if not pre-loaded each MCO will be pulled down individually. -->
<!-- -->
<!-- Example entries: -->
<!-- -->
<!-- <archive url="http://blah:18/foo.jar" /> -->
<!-- <archive path="/WEB-INF/client/lib/foo.jar" /> -->
<!-- This is the default directory for MCO classes. -->
<directory path="/WEB-INF/client/classes/" />
</client-classpath>
<!-- =================================================================== -->
<!-- Session Configurations -->
<!-- =================================================================== -->
<session-configurations>
<!-- In this section you can define session configuration templates that -->
<!-- match particular client profiles. If the client does not match any -->
<!-- of the defined session configuration templates the default one is -->
<!-- used. If a template does not explicitly specify some setting values, -->
<!-- the default values will be taken from the default template. -->
<!-- If you define flush policies within a session configuration template -->
<!-- only those policies will be available to the client that matches the -->
<!-- session template. You can omit matching rules inside a flush policy -->
<!-- in which case it simply inherits the rules of the enclosing session -->
<!-- template. The rules for a flush policy should not conflict with the -->
<!-- rules of the enclosing session template since the policy will never -->
<!-- get used. -->
<!-- The <match> element for the session config template rules as well as -->
<!-- flush policy rules supports ONE of two attributes: -->
<!-- -->
<!-- xpath - Evaluated as boolean against sessions' ClientInfo XML -->
<!-- document. -->
<!-- -->
<!-- address - An IPv4 address that the open push connection must come -->
<!-- from in order to have this policy applied. Wildcards are -->
<!-- supported in each part, as the whole part only. The wildcard -->
<!-- character is '*'. All four parts of the IPv4 address must be -->
<!-- present. -->
<!-- -->
<!-- Only one match element with the 'address' attribute is supported -->
<!-- per configuration. If more than one element with the 'address' -->
<!-- attribute is present, only the first one will be used. -->
<!-- Here is an example of a custom session configuration template: -->
<!--
<session-configuration>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration>
<polling-interval>15 seconds</polling-interval>
<begin-polling-on-startup>false</begin-polling-on-startup>
<establish-push-connection-on-startup>false</establish-push-connection-on-startup>
<reliable-messaging-enabled>false</reliable-messaging-enabled>
<push-connection-flush-policies>
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodFlushPolicy">
<flush-size>5 K</flush-size>
<period>100 millis</period>
</configuration>
</policy>
</push-connection-flush-policies>
</configuration>
</session-configuration>
-->
<!-- -->
<!-- =================================================================== -->
<!-- Default Session Configuration -->
<!-- =================================================================== -->
<!-- This section defines the default session configuration. -->
<!-- If a custom session configuration template does not specify values -->
<!-- for some settings, the values will be taken from this section. -->
<default-session-configuration>
<configuration>
<!-- "polling-interval" defines the maximum interval allowed between -->
<!-- client requests when polling is active. When polling is active, -->
<!-- the client will make automatically make requests to the server -->
<!-- based on the polling interval. -->
<!-- -->
<!-- Polling is useful when you wish to ensure that the client and -->
<!-- server send updates to each other on a regular basis but you -->
<!-- don't wish to have an open push connection and there aren't -->
<!-- regular user generated requests from the client. -->
<!-- -->
<!-- A positive value is required when using reliable messaging and if -->
<!-- none is supplied, the default reliable messaging interval will be -->
<!-- used. -->
<polling-interval>15 seconds</polling-interval>
<!-- Whether polling is begun when sessions are first created. It is -->
<!-- also possible to start and stop polling from the client side -->
<!-- programmatically. -->
<!-- -->
<!-- Note that when reliable messaging is enabled, this value MUST be -->
<!-- true. If not specified as true when reliable messaging is -->
<!-- enabled, Nexaweb will set the value to true at session creation -->
<!-- time. -->
<begin-polling-on-startup>false</begin-polling-on-startup>
<!-- Whether a push connection is created when sessions are first -->
<!-- created. It is also possible to open and close push connections -->
<!-- programmatically. -->
<establish-push-connection-on-startup>false</establish-push-connection-on-startup>
<!-- Whether reliable messaging between the client and server should -->
<!-- be enabled. -->
<reliable-messaging-enabled>false</reliable-messaging-enabled>
<!-- When using reliable messaging, all outgoing messages and incoming -->
<!-- messages received out of order are cached for the possibility of -->
<!-- a resend (outgoing) or delivery (incoming). Outgoing messages -->
<!-- are cached until an acknowledgement is received, or they time -->
<!-- out. Incoming messages received out of order are cached as well -->
<!-- until later delivery or they time out. The parameter below is -->
<!-- the time messages will be kept in either cache before being -->
<!-- removed (TTL). -->
<!-- -->
<!-- Note that the larger this value is, the more resources will be in -->
<!-- use when there are network issues or a client goes away without -->
<!-- exiting the session. The smaller this value is, the fewer -->
<!-- resources will be in use, but also the tolerance for network -->
<!-- issues will be lower. This setting needs to be set based on your -->
<!-- application profile and the reliability of the networks you are -->
<!-- dealing with. It is also important that this value be some -->
<!-- reasonable multiple of the polling-interval specified above. The -->
<!-- interval determines how often client and server can sync up when -->
<!-- messages get lost so if the message TTL is not large enough in -->
<!-- relation to the polling interval it is likely the messages will -->
<!-- expire before client and server have a chance to perform any -->
<!-- resends if necessary. -->
<!-- -->
<!-- This value is only used when reliable messaging is enabled. -->
<message-time-to-live>45 sec</message-time-to-live>
<!-- When using reliable messaging, all outgoing messages and incoming -->
<!-- messages received out of order are cached for the possibility of -->
<!-- a resend (outgoing) or delivery (incoming). The value below is -->
<!-- the period for the task that examines both message caches and -->
<!-- removes expired messages. Messages are removed when they have -->
<!-- outlived the message-time-to-live. -->
<message-cache-cleanup-task-period>30 sec</message-cache-cleanup-task-period>
<!-- This value determines whether the server will keep a copy of the -->
<!-- UI Document. In most cases keeping the UI Document on the server -->
<!-- is not recommended. For synchronized data, use datasets or use -->
<!-- messaging to send information between the client and server. It -->
<!-- is also possible to use form submission to post form-encoded data -->
<!-- to the server-side rather than to look up values from the -->
<!-- server-side UI Document. -->
<server-ui-dom-enabled>false</server-ui-dom-enabled>
<push-connection-flush-policies>
<!-- When PushConnections are created, Nexaweb Server will first -->
<!-- attempt to find a matching session configuration template. If -->
<!-- there is a match it will try to get the push-connection-flush- -->
<!-- policies block from there and match the policies in order. If the -->
<!-- policies block is not defined within the session configuration -->
<!-- template, Nexaweb Server will look for the push-connection-flush- -->
<!-- policies block in the default session configuration defined in -->
<!-- your webapp. If it's not there, the server wide config's default -->
<!-- session configuration will be searched. Once a push-connection- -->
<!-- flush-policies is encountered, only the policies defined within -->
<!-- that block will be used. No further searching will be done. In -->
<!-- order for a policy to be applied, each "match" expression must -->
<!-- evaluate to a boolean true. -->
<!-- -->
<!-- Example ClientInfo XML: -->
<!-- -->
<!-- <client-info> -->
<!-- <client-version>Nexaweb Platform v4.1</client-version> -->
<!-- <java-version>1.4.2</java-version> -->
<!-- <java-vendor>Sun Microsystems Inc.</java-vendor> -->
<!-- <os>Windows XP</os> -->
<!-- <os-version>5.1</os-version> -->
<!-- <browser>sun.plugin</browser> -->
<!-- <architecture>x86</architecture> -->
<!-- <user-agent>Mozilla/4.0 (compatible; MSIE 6.0; Windows NT )</user-agent> -->
<!-- <screen-size>1600,1200</screen-size> -->
<!-- <is-connection-secure>true</is-connection-secure> -->
<!-- <locale>en,US,</locale> -->
<!-- <is-connection-secure>false</is-connection-secure> -->
<!-- </client-info> -->
<!-- Example policies: -->
<!--
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.ThroughputFlushPolicy">
<flush-size>8 K</flush-size>
<measurement-period>10 sec.</measurement-period>
<minimum-throughput>4K</minimum-throughput>
</configuration>
</policy>
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodWithSizeThresholdFlushPolicy">
<flush-size>8 K</flush-size>
<period>10 sec.</period>
<message-size-threshold>200 bytes</message-size-threshold>
</configuration>
</policy>
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodFlushPolicy">
<flush-size>8 K</flush-size>
<period>10 sec.</period>
</configuration>
</policy>
</push-connection-flush-policies>
-->
<!-- Default flush policy for Microsoft JVM -->
<!-- -->
<!-- Microsoft JVM causes the last push message to be buffered and not -->
<!-- available to the NexawebClient. This flush policy will generate -->
<!-- an empty message and flush the regular message out of the buffer -->
<!-- so that it can be processed. This should be adjusted to match the -->
<!-- use patterns of your application. -->
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.1')" />
<match xpath="starts-with(/client-info/java-vendor, 'Microsoft')" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodFlushPolicy">
<flush-size>5 K</flush-size>
<period>100 millis</period>
</configuration>
</policy>
</push-connection-flush-policies>
</configuration>
</default-session-configuration>
</session-configurations>
<!-- =================================================================== -->
<!-- Launch Configuration -->
<!-- =================================================================== -->
<!-- This section allows for the customization of the default Nexaweb -->
<!-- Client launch pages. If you have written your own launch pages, -->
<!-- these values will not have any effect on your application. -->
<!-- -->
<!-- Each of the values specified below may be overridden INDIVIDUALLY in -->
<!-- your application's local client.xml file. Thus, it is recommended -->
<!-- that you do NOT copy the entire section to override one value, but -->
<!-- rather just the value itself. -->
<!-- -->
<!-- Example: -->
<!-- -->
<!-- If you wished to override the applet width, you would place the -->
<!-- following XML in your client.xml file: -->
<!-- -->
<!-- <client-launch-configuration> -->
<!-- <applet-width>50%</applet-width> -->
<!-- </client-launch-configuration> -->
<!-- -->
<!-- There is no need to copy the entire section. In this way it will be -->
<!-- easy to figure out what you have customized and what you have not. -->
<launch-configuration>
<!-- The title of the browser window that displays the Nexaweb -->
<!-- application. -->
<window-title>Welcome To Nexaweb</window-title>
<!-- Parameters can be arbitrarily written into the client and read -->
<!-- back out through a client-side API. -->
<applet-parameters>
<!-- Example applet parameter name/value pair: -->
<!-- <param name="User Name" value="James Joyce" /> -->
</applet-parameters>
<!-- The start page of the Nexaweb application. The index.jsp file -->
<!-- will launch the application from this page. -->
<initial-page>java-index.xal</initial-page>
<!-- When true, the un-obfuscated Nexaweb client jars will be used. -->
<ui-test>false</ui-test>
<!-- Sets the type of application being run. The application type is -->
<!-- used to identify valid namespaces and root tags for XML documents. -->
<!-- Possible values -->
<!-- XAL - xal complient apps created with 4.5.1 or higher. -->
<!-- NXML - allow pre 4.5 syntax -->
<application-type>XAL</application-type>
<!-- When true, the jar containing the Nexaweb Foundation Classes -->
<!-- (NFC) will be written in the applet definition to make them -->
<!-- available for use on the client side. When false, the NFC -->
<!-- classes will not be written in the applet definition and NFC will -->
<!-- not be usable on the client side unless the jar is manually added -->
<!-- to the classpath. -->
<nfc>false</nfc>
<!-- When false, Nexaweb JvmDetector will continue to load the Nexaweb -->
<!-- client even if an unknown Jvm is detected. -->
<!-- -->
<!-- When true, Nexaweb JvmDetector will prompt to the user that the -->
<!-- JVM has not been tested and the user can choose to continue. -->
<display-unknown-vm-in-status>false</display-unknown-vm-in-status>
<!-- Timeout value for loading the Nexaweb client. The unit is minute. -->
<!-- If the client can't be loaded in this interval, timeout message -->
<!-- will be displayed on the screen. -->
<!-- -->
<!-- The default value is 3 which means 3 minutes. -->
<applet-load-timeout>3</applet-load-timeout>
<!-- The Applet class used to launch Nexaweb. Users should not need to -->
<!-- change this value. -->
<applet-class>com.nexaweb.client.launcher.DefaultJvmDetector.class</applet-class>
<!-- The launch-ui section allows users to customize the look of the -->
<!-- Nexaweb-loading screen. -->
<launch-ui>
<!-- After 4.2, do not change "class=" assignment -->
<progress-handler class="com.nexaweb.client.launcher.DefaultProgressHandler">
<!-- default: #FFFFFF -->
<background-color>#FFFFFF</background-color>
<!-- Passed to progress-handler; DefaultProgressHandler ignores. -->
<!-- <bar-color>#C0C0C0</bar-color> -->
<!-- default: empty -->
<image-path>classpath://com/nexaweb/client/launcher/images/empty.gif</image-path>
<!-- default: empty; DefaultProgressHandler only. -->
<bar-image-path>classpath://com/nexaweb/client/launcher/images/animated_start.gif</bar-image-path>
<!-- default: empty-->
<!-- <title>Launching Nexaweb Client</title> -->
<!-- default: auto generated like 4.1.0.3456 -->
<!-- <version></version> -->
<!-- default: empty -->
<display>Initializing...</display>
<!-- default: left; can also be "center" or "right"; since 4.2, -->
<!-- horizontal page element alignment, DefaultProgressHandler only.-->
<align>left</align>
<!-- default: SansSerif; since 4.2, font face used in page elements,-->
<!-- DefaultProgressHandler only. Logical fonts Serif, SansSerif, -->
<!-- Dialog, DialogInput, and Monospaced exist on all client -->
<!-- computers; physical fonts such as "Arial" may not. -->
<fontface>SansSerif</fontface>
<!-- shows a "more info" button in case JVM cannot be determined if true -->
<show-unknown-vm-status>true</show-unknown-vm-status>
</progress-handler>
</launch-ui>
<!-- Specify requirements needed to run the client. If these are not met
an error is displayed onscreen with a button that links to the error page. -->
<launch-requirements>
<jvm-version>
<!-- The client will display an error if the JVM being used
in not in the list of JVMs to include, or if it is in the list
of JVMs to exlcude. You can specify multiple include and
exclude tags. -->
<!-- '*' is a special character that means matches all. It can not
be used in any other sort of pattern matching. -->
<include>*</include>
<!-- Use exclude to exclude certain JVMs. -->
<!-- <exclude></exclude> -->
<!-- more examples: This example creates an app that will run with
any 1.4 JVM except 1.4.0 and also with 1.3.2_02
<include>1.4</include>
<include>1.3.2_02</include>
<exclude>1.4.0</exclude>
-->
</jvm-version>
<!-- Similar to jvm-version, you can include and exclude vendors.
The string in the include or exlude is checked to see if it
is contained in the "java.vendor" property. For example
"sun" would match against the Sun plug-in which reports
"Sun Microsystems" as the java.vendor-->
<jvm-vendor>
<include>*</include>
<!-- <exclude></exclude> -->
</jvm-vendor>
<!-- This matching is the same as jvm-version except that it checks
against the user-agent as reported by the web-browser. -->
<user-agent>
<include>*</include>
<!-- <exclude></exclude> -->
</user-agent>
<!-- Specifies the minimum screen resolution the client must have -->
<minimum-screen-resolution>
<width>0</width>
<height>0</height>
</minimum-screen-resolution>
<!-- If the client does not meet the launch requirements an error message
will appear with a button that links to the given page. Like other
Nexaweb error pages this page will be passed client information
as paramters in the URL string. The "exception" parameter will
indicate the reason the client did not meet launch requirements.
It will be one of:
jvm-version-not-included
jvm-version-excluded
jvm-vendor-not-included
jvm-vendor-excluded
user-agent-not-included
user-agent-excluded
minimum-screen-resolution-width
minimum-screen-resolution-height
-->
<error-page>Nexaweb/jsp/launcher/errorLaunchRequirementsNotMet.jsp</error-page>
</launch-requirements>
<!-- ======================================================== -->
<!-- These two values should not be modified by the user. -->
<applet-width>100%</applet-width>
<applet-height>100%</applet-height>
<launch-error-pages>
<!-- ====================================================== -->
<!-- The values here may be specified in one of three forms -->
<!-- 1 - Fully qualified URLs. These are recognized by -->
<!-- Nexaweb's code because they start with "http://"-->
<!-- or "https://". -->
<!-- 2 - Fully qualified URIs that include the web app -->
<!-- containing the error pages. These are -->
<!-- recognized by Nexaweb's code because the start -->
<!-- with a "/" character. -->
<!-- 3 - A path relative to your web application root. -->
<!-- All values that do not meet the criteria for -->
<!-- cases 1 and 2 will be treated as such. -->
<buggy-vm>Nexaweb/jsp/launcher/errorBuggyVM.jsp</buggy-vm>
<bad-vm>Nexaweb/jsp/launcher/errorBadVM.jsp</bad-vm>
<loading-timed-out>Nexaweb/jsp/launcher/errorLoadingTimedout.jsp</loading-timed-out>
<loading-failed>Nexaweb/jsp/launcher/errorLoadingFailed.jsp</loading-failed>
<starting-failed>Nexaweb/jsp/launcher/errorStartingFailed.jsp</starting-failed>
<delete-no-cab-cookie>Nexaweb/jsp/launcher/deleteNocabCookie.jsp</delete-no-cab-cookie>
</launch-error-pages>
<!-- =========================================================== -->
<!-- This boolean value determines whether or not the start page -->
<!-- will allow the "initialPage" URL parameter to override the -->
<!-- initial page specified in the configuration. This is often -->
<!-- set to true in a test or development environment, but will -->
<!-- likely be false in a production environment where a specific-->
<!-- workflow must be enforced. -->
<allow-url-parameter-for-initial-page>false</allow-url-parameter-for-initial-page>
<!-- ================================================== -->
<!-- This value is commented out because when the value -->
<!-- is NOT supplied here, each applet def written will -->
<!-- get a Unique ID. Use this value to customize the -->
<!-- ID of the applet written in order to address it in -->
<!-- javascript. -->
<!-- -->
<!-- To write more than one nexaweb applet on a page, -->
<!-- with known IDs instead of generated UIDs, you must -->
<!-- customize the writing of the applet tag. -->
<!-- <applet-id>custom-id</applet-id> -->
<!-- ================================================== -->
<!-- This value should be used when there is some -->
<!-- network hardware between the client and server -->
<!-- performing URL re-writing. Put the URL re-writer -->
<!-- context path here to ensure that the client's -->
<!-- requests are sent to the intervening hardware or -->
<!-- software with the correct context. -->
<!-- <context-path-override></context-path-override> -->
</launch-configuration>
<!-- =================================================================== -->
<!-- User-defined tag mapping files. -->
<!-- =================================================================== -->
<!-- This defines a set of configuration files used by the plug-in -->
<!-- architecture to map custom tag names in UI XML to tag-handling -->
<!-- implementation classes. See the documentation on the plug-in -->
<!-- architecture for details. -->
<client-tag-mapping>
<!-- Example tag mapping file definition: -->
<!-- <tag-map-file>Foo.map</tag-map-file> -->
</client-tag-mapping>
<!-- =================================================================== -->
<!-- Stylesheets. -->
<!-- =================================================================== -->
<!-- Defines at most one default stylesheet and any number of other -->
<!-- stylesheets that will be loaded on startup by the application. If no -->
<!-- default stylesheet is specified here "defaultstylesheet.txt" from -->
<!-- inside the client jar file is used. -->
<!-- -->
<!-- Example stylesheet declarations: -->
<!-- -->
<!--
<style-sheets>
<default-style-sheet>exampleSheet.xss</default-style-sheet>
<style-sheet>exampleSheet1.xss</style-sheet>
<style-sheet>exampleSheet2.xss</style-sheet>
</style-sheets>
-->
<style-sheets/>
<!-- =================================================================== -->
<!-- Client Log Settings -->
<!-- =================================================================== -->
<!-- default-log level specifies the default logging level for the -->
<!-- This can be overridden by individual log settings. -->
<log-configuration default-log-level="exception">
<!-- An example of specifying log level on an indvidual log -->
<!-- <log name="XModify" log-level="debug" /> -->
<consumers>
<!-- Be default two log consumers are included: one that logs all -->
<!-- messages to the console, and one that logs only error/exception -->
<!-- to a modal dialog. -->
<consumer class="com.nexaweb.util.ConsoleLogConsumer" />
<consumer class="com.nexaweb.client.log.DialogLogConsumer" />
</consumers>
</log-configuration>
<!-- =================================================================== -->
<!-- Tooltip delay setting (milliseconds) -->
<!-- =================================================================== -->
<tooltip-delay>500</tooltip-delay>
<!-- =================================================================== -->
<!-- Tab to radio groups -->
<!-- -->
<!-- Indicates whether or not to treat a group of radio buttons as -->
<!-- one tabbable component, so tabbing would occur to a set of radio -->
<!-- buttons and the arrow keys would be used to traverse the group. -->
<!-- -->
<!-- Possible settings: -->
<!-- true indicates to tab to the group, false (default) indicates -->
<!-- that the tab key should proceed through each radio button -->
<!-- individually. -->
<!-- =================================================================== -->
<tab-to-radio-groups>false</tab-to-radio-groups>
<!-- =================================================================== -->
<!-- Window deactivation policy -->
<!-- -->
<!-- Indicates what action to take when the main client frame is -->
<!-- deactivated, for example by clicking away from the browser window -->
<!-- to use another application. -->
<!-- -->
<!-- Possible settings: -->
<!-- release-focus -->
<!-- Unfocus the current focused component, and re-focus when the -->
<!-- window reactivates. This is the default behavior. -->
<!-- disable-cursor-blink -->
<!-- Stop the cursor from blinking, has no effect on the focus. -->
<!-- none -->
<!-- Take no action. -->
<!-- =================================================================== -->
<window-deactivation-policy>release-focus</window-deactivation-policy>
<!-- =================================================================== -->
<!-- Indicates whether or not to keep the last client event which was -->
<!-- fired. -->
<!-- This may be set to true if a legacy application requires the event -->
<!-- to remain in memory after an event fires. This will cause all -->
<!-- memory structures related to the event to be held until the next -->
<!-- event occurs, so it should be used with caution in applications -->
<!-- with large memory requirements. -->
<!-- =================================================================== -->
<keep-last-client-event>false</keep-last-client-event>
<!-- =================================================================== -->
<!-- Indicates whether or not to allow the client to call out to a -->
<!-- javascript method to open a new browser. This is used to overcome -->
<!-- an issue with the latest java plugin enhancements which opens the -->
<!-- new browser window behind the existing application window. -->
<!-- The default is "true". If there are issues in a supported browser -->
<!-- for a particular environment, this may be set to "false" which will -->
<!-- have the client use the applet's open browser call as was the -->
<!-- previous implementation. If any exception occurs attempting to make -->
<!-- the javascript call out, the applet's open browser call will be -->
<!-- used. -->
<!-- =================================================================== -->
<javascript-browser-open-enabled>true</javascript-browser-open-enabled>
<!-- =================================================================== -->
<!-- In multithreaded UI applications that require extra synchronization -->
<!-- on the server, set this to true to indicate that the client should -->
<!-- synchronize when constructing nexaweb server messages with requests -->
<!-- =================================================================== -->
<synchronize-nexaweb-server-requests>false</synchronize-nexaweb-server-requests>
<!-- =================================================================== -->
<!-- In multithreaded UI applications that use persistent connections, -->
<!-- this value indicates to open the push connection cleanly, ensuring -->
<!-- that there will be no possibility for timing issues transmitting -->
<!-- outbound client information to the server when a push connection -->
<!-- needs to re-establish. -->
<!-- It is not recommended to change this setting. -->
<!-- If synchronize-nexaweb-server-requests is set to true, this setting -->
<!-- will have no effect, and the push connection will ALWAYS be opened -->
<!-- without additional outbound protocol information, regardless. -->
<!-- =================================================================== -->
<open-push-without-protocol>true</open-push-without-protocol>
<!-- =================================================================== -->
<!-- Anti-aliasing -->
<!-- =================================================================== -->
<!-- The minimum font size to anti-alias. All label/button text of this -->
<!-- size or above will be rendered anti-aliased. -->
<anti-alias-minimum-font-size>18</anti-alias-minimum-font-size>
<!-- =================================================================== -->
<!-- Backwards compatibility settings -->
<!-- =================================================================== -->
<!-- Starting in 4.1, the HttpRequest will adjust the request method -->
<!-- internally unless user chooses to be backwards compatible with 4.0 -->
<!-- behavior. In 4.0, the request method is always false. -->
<is-http-request-4_0-compatible>false</is-http-request-4_0-compatible>
<!-- Starting in 4.1, pressing F1 or F2 will no longer print out the UI -->
<!-- DOM unless this setting is enabled. -->
<debug-keys-enabled>true</debug-keys-enabled>
<!-- Starting in 4.2, this can be set true to internally resignal -->
<!-- keyPress events incorrectly so that QuickTestPro will record them -->
<!-- correctly. Default is false. -->
<!-- NOTE: -->
<!-- Although this setting is still valid, there is now a patch -->
<!-- available from Mercury that addresses this issue. It is -->
<!-- recommended that you contact your Mercury representative -->
<!-- and request the patch. Refer to the platform documentation for -->
<!-- information on how to obtain the patch from Mercury. -->
<quick-test-pro-record-fix>false</quick-test-pro-record-fix>
<!-- Starting in 4.1, when an MCO event is called as an event handler -->
<!-- the glass pane is displayed without a wait cursor unless this -->
<!-- setting is enabled. -->
<display-wait-cursor-for-mco-calls>false</display-wait-cursor-for-mco-calls>
<!-- This parameter is supplied so that parsing of MCO string arguments can be -->
<!-- the same as in pre-4.2 versions. In 4.2 \" is converted to ", \\ is -->
<!-- converted to \, and \x where x is not a valid escape sequence is an -->
<!-- error. This is similar to the way strings are escaped in Java code. In 4.1 -->
<!-- \" is converted to " only. \\ is not converted to \ and freestanding \ -->
<!-- characters are allowed. -->
<ensure-pre-4-dot-2-mco-string-argument-compatibility>false</ensure-pre-4-dot-2-mco-string-argument-compatibility>
<!-- This parameter is supplied so that the macro code can know NOT -->
<!-- to use MessageFormat for the macro strings. in 4.2 we added parameters -->
<!-- which use MessageFormat, thus single tick escaping is required in 4.2 -->
<!-- plus. We want existing macros to work if the customer so desires. -->
<ensure-pre-4-dot-2-macro-compatibility>false</ensure-pre-4-dot-2-macro-compatibility>
<!-- This parameter is supplied so that the client can know NOT to -->
<!-- interpret {...} in attributes and text nodes as items needing -->
<!-- resolution. When this is set to true {...} is not interpreted in -->
<!-- in any way and { and } do not need to be escaped. -->
<ensure-pre-4-dot-2-resolution-syntax-compatibility>false</ensure-pre-4-dot-2-resolution-syntax-compatibility>
<!-- This parameter provides backwards compatibility support for customers which require -->
<!-- (count-on) the bug where a state change is reported on the client when the mouse is -->
<!-- pressed on a row or cell (or listItem in a listBox). When set to true the client -->
<!-- will always report an onStateChangeEvent when the mouse is pressed on a row or cell, -->
<!-- even when the state has not changed -->
<ensure-pre-bugfix-table-statechange-behavior-onmousedown>false</ensure-pre-bugfix-table-statechange-behavior-onmousedown>
<!-- This parameter is used so the XUpdate behavior can be the same as in pre-4.2 -->
<!-- versions. In pre 4.2 versions the root element of a Document is always used -->
<!-- as the context object when evaluating XUpdate directives. In 4.2 and later -->
<!-- the Document object is used as the context. -->
<use-root-element-as-context-instead-of-document>false</use-root-element-as-context-instead-of-document>
<!-- These two parameters are used in conjunction with automate test tools such -->
<!-- as Quick Test Pro. generate-unique-ids ensures that a unique test id can be retrieved -->
<!-- from the component and used for identification purposes. show-ancestors indicates -->
<!-- whether or not to include the names of the ancestors of the component, when generating the test id. -->
<!--
<testids>
<generate-unique-ids>true</generate-unique-ids>
<show-ancestors>false</show-ancestors>
</testids>
-->
<!-- This parameter enables using HTTP request header to store Nexaweb session id. When the -->
<!-- parameter is omitted or its value is false, the Nexaweb session id is sent in a cookie; when -->
<!-- true, the session id is sent in a request header X-NXSESSIONID. Some proxy severs may strip -->
<!-- non-standard request headers. When the header X-NXSESSIONID is not stripped, setting this -->
<!-- this parameter to true can be used for supporting multiple sessions per browser instance. -->
<!--
<use-http-request-header-for-session-id>true</use-http-request-header-for-session-id>
-->
<!-- This parameter provides an option to use Windows style for restoring windows i.e. using -->
<!-- restore button always restores back to normal window size. When the parameter is omitted or -->
<!-- its value is false, it will use unix style which restores windows to pre maximized state. -->
<!--
<windows-style-restore>true</windows-style-restore>
-->
<!-- This parameter provides backwards compatibility support for customers who want to be able to-->
<!-- use mousewheel to scroll bar in a disabled component. When the parameter is omitted or -->
<!-- its value is true, it will ignore mouse wheel event on disabled components. -->
<!--
<ignore-scrollWheelEvent-on-disabled>false</ignore-scrollWheelEvent-on-disabled>
-->
<!-- This parameter is used to define the quality of a upscaled or downscaled image. Value can be -->
<!-- either "high" or "low"; default value for both is low. When the value is set high for a -->
<!-- downscaled image, and the scale factor is more than two,in order to obtain a higher quality -->
<!-- image, we repeatedly scale the image by half till we've got the target image and save all -->
<!-- scaled image instances. Thus it require higher processing time and memory resource -->
<!--
<image-draw-policy>
<upscale-quality>low</upscale-quality>
<downscale-quality>low</downscale-quality>
</image-draw-policy>
-->
</client-app>
<!-- $Revision: 64296 $ -->
<client-app version="$Revision: 64296 $">
<!-- =================================================================== -->
<!-- Client Classpath ( Customer Code ). -->
<!-- =================================================================== -->
<client-classpath>
<!-- Archives and directories included in the client-classpath may be -->
<!-- specified with paths or URLs. Where a path may be converted to a -->
<!-- file reference, up-to-date checks will be performed as resources -->
<!-- are returned. For all URLs and for paths that can not be -->
<!-- converted to a file reference (for instance if deployed in a WAR -->
<!-- file), no up-to-date checks will be performed. -->
<!-- -->
<!-- About paths: -->
<!-- There are two methods used to resolve the specified paths. The -->
<!-- first method is ServletContext.getRealPath(). If this method -->
<!-- returns null, then ServletContext.getResource() is used to -->
<!-- resolve the path. Therefore paths specified must conform to the -->
<!-- specification for the two ServletContext methods. See the -->
<!-- ServletContext javadocs for more information. -->
<pre-loaded-in-applet-def>
<!-- Pre-loaded archives are archives that will be written into -->
<!-- the applet definition tag directly. These archives are served -->
<!-- to the client in their entirety, not as individual -->
<!-- files. Only "archive" elements may be pre-loaded in the -->
<!-- applet definition. All "archive" elements that are included -->
<!-- in this section must contain the "name" attribute and that -->
<!-- attribute value must be unique across archives. -->
<!-- -->
<!-- Pre-loaded archives also support pack200-gzip files. User -->
<!-- can specify such files using a 'pack200Path' or 'pack200Url' -->
<!-- attribute. You only need to specify a path or a URL. If you -->
<!-- specify both, the path will take the precedence. -->
<!-- The same rule applies to 'pack200Path' and 'pack200Url' -->
<!-- -->
<!-- Example entry: -->
<!-- -->
<!-- <archive name="MyLibrary.jar" -->
<!-- path="/WEB-INF/client/lib/MyLib.jar" -->
<!-- pack200Path="/WEB-INF/client/lib/MyLib.jar.pack.gz" /> -->
</pre-loaded-in-applet-def>
<!-- Classpath items that are not pre-loaded can be archives or -->
<!-- directories. Unlike pre-loaded archives, these entries are searched -->
<!-- for individual files that are served one at a time rather than as -->
<!-- entire archives. For example, a jar file with 10 MCOs that is -->
<!-- pre-loaded will be pulled down by the client as a single jar file, -->
<!-- but if not pre-loaded each MCO will be pulled down individually. -->
<!-- -->
<!-- Example entries: -->
<!-- -->
<!-- <archive url="http://blah:18/foo.jar" /> -->
<!-- <archive path="/WEB-INF/client/lib/foo.jar" /> -->
<!-- This is the default directory for MCO classes. -->
<directory path="/WEB-INF/client/classes/" />
</client-classpath>
<!-- =================================================================== -->
<!-- Session Configurations -->
<!-- =================================================================== -->
<session-configurations>
<!-- In this section you can define session configuration templates that -->
<!-- match particular client profiles. If the client does not match any -->
<!-- of the defined session configuration templates the default one is -->
<!-- used. If a template does not explicitly specify some setting values, -->
<!-- the default values will be taken from the default template. -->
<!-- If you define flush policies within a session configuration template -->
<!-- only those policies will be available to the client that matches the -->
<!-- session template. You can omit matching rules inside a flush policy -->
<!-- in which case it simply inherits the rules of the enclosing session -->
<!-- template. The rules for a flush policy should not conflict with the -->
<!-- rules of the enclosing session template since the policy will never -->
<!-- get used. -->
<!-- The <match> element for the session config template rules as well as -->
<!-- flush policy rules supports ONE of two attributes: -->
<!-- -->
<!-- xpath - Evaluated as boolean against sessions' ClientInfo XML -->
<!-- document. -->
<!-- -->
<!-- address - An IPv4 address that the open push connection must come -->
<!-- from in order to have this policy applied. Wildcards are -->
<!-- supported in each part, as the whole part only. The wildcard -->
<!-- character is '*'. All four parts of the IPv4 address must be -->
<!-- present. -->
<!-- -->
<!-- Only one match element with the 'address' attribute is supported -->
<!-- per configuration. If more than one element with the 'address' -->
<!-- attribute is present, only the first one will be used. -->
<!-- Here is an example of a custom session configuration template: -->
<!--
<session-configuration>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration>
<polling-interval>15 seconds</polling-interval>
<begin-polling-on-startup>false</begin-polling-on-startup>
<establish-push-connection-on-startup>false</establish-push-connection-on-startup>
<reliable-messaging-enabled>false</reliable-messaging-enabled>
<push-connection-flush-policies>
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodFlushPolicy">
<flush-size>5 K</flush-size>
<period>100 millis</period>
</configuration>
</policy>
</push-connection-flush-policies>
</configuration>
</session-configuration>
-->
<!-- -->
<!-- =================================================================== -->
<!-- Default Session Configuration -->
<!-- =================================================================== -->
<!-- This section defines the default session configuration. -->
<!-- If a custom session configuration template does not specify values -->
<!-- for some settings, the values will be taken from this section. -->
<default-session-configuration>
<configuration>
<!-- "polling-interval" defines the maximum interval allowed between -->
<!-- client requests when polling is active. When polling is active, -->
<!-- the client will make automatically make requests to the server -->
<!-- based on the polling interval. -->
<!-- -->
<!-- Polling is useful when you wish to ensure that the client and -->
<!-- server send updates to each other on a regular basis but you -->
<!-- don't wish to have an open push connection and there aren't -->
<!-- regular user generated requests from the client. -->
<!-- -->
<!-- A positive value is required when using reliable messaging and if -->
<!-- none is supplied, the default reliable messaging interval will be -->
<!-- used. -->
<polling-interval>15 seconds</polling-interval>
<!-- Whether polling is begun when sessions are first created. It is -->
<!-- also possible to start and stop polling from the client side -->
<!-- programmatically. -->
<!-- -->
<!-- Note that when reliable messaging is enabled, this value MUST be -->
<!-- true. If not specified as true when reliable messaging is -->
<!-- enabled, Nexaweb will set the value to true at session creation -->
<!-- time. -->
<begin-polling-on-startup>false</begin-polling-on-startup>
<!-- Whether a push connection is created when sessions are first -->
<!-- created. It is also possible to open and close push connections -->
<!-- programmatically. -->
<establish-push-connection-on-startup>false</establish-push-connection-on-startup>
<!-- Whether reliable messaging between the client and server should -->
<!-- be enabled. -->
<reliable-messaging-enabled>false</reliable-messaging-enabled>
<!-- When using reliable messaging, all outgoing messages and incoming -->
<!-- messages received out of order are cached for the possibility of -->
<!-- a resend (outgoing) or delivery (incoming). Outgoing messages -->
<!-- are cached until an acknowledgement is received, or they time -->
<!-- out. Incoming messages received out of order are cached as well -->
<!-- until later delivery or they time out. The parameter below is -->
<!-- the time messages will be kept in either cache before being -->
<!-- removed (TTL). -->
<!-- -->
<!-- Note that the larger this value is, the more resources will be in -->
<!-- use when there are network issues or a client goes away without -->
<!-- exiting the session. The smaller this value is, the fewer -->
<!-- resources will be in use, but also the tolerance for network -->
<!-- issues will be lower. This setting needs to be set based on your -->
<!-- application profile and the reliability of the networks you are -->
<!-- dealing with. It is also important that this value be some -->
<!-- reasonable multiple of the polling-interval specified above. The -->
<!-- interval determines how often client and server can sync up when -->
<!-- messages get lost so if the message TTL is not large enough in -->
<!-- relation to the polling interval it is likely the messages will -->
<!-- expire before client and server have a chance to perform any -->
<!-- resends if necessary. -->
<!-- -->
<!-- This value is only used when reliable messaging is enabled. -->
<message-time-to-live>45 sec</message-time-to-live>
<!-- When using reliable messaging, all outgoing messages and incoming -->
<!-- messages received out of order are cached for the possibility of -->
<!-- a resend (outgoing) or delivery (incoming). The value below is -->
<!-- the period for the task that examines both message caches and -->
<!-- removes expired messages. Messages are removed when they have -->
<!-- outlived the message-time-to-live. -->
<message-cache-cleanup-task-period>30 sec</message-cache-cleanup-task-period>
<!-- This value determines whether the server will keep a copy of the -->
<!-- UI Document. In most cases keeping the UI Document on the server -->
<!-- is not recommended. For synchronized data, use datasets or use -->
<!-- messaging to send information between the client and server. It -->
<!-- is also possible to use form submission to post form-encoded data -->
<!-- to the server-side rather than to look up values from the -->
<!-- server-side UI Document. -->
<server-ui-dom-enabled>false</server-ui-dom-enabled>
<push-connection-flush-policies>
<!-- When PushConnections are created, Nexaweb Server will first -->
<!-- attempt to find a matching session configuration template. If -->
<!-- there is a match it will try to get the push-connection-flush- -->
<!-- policies block from there and match the policies in order. If the -->
<!-- policies block is not defined within the session configuration -->
<!-- template, Nexaweb Server will look for the push-connection-flush- -->
<!-- policies block in the default session configuration defined in -->
<!-- your webapp. If it's not there, the server wide config's default -->
<!-- session configuration will be searched. Once a push-connection- -->
<!-- flush-policies is encountered, only the policies defined within -->
<!-- that block will be used. No further searching will be done. In -->
<!-- order for a policy to be applied, each "match" expression must -->
<!-- evaluate to a boolean true. -->
<!-- -->
<!-- Example ClientInfo XML: -->
<!-- -->
<!-- <client-info> -->
<!-- <client-version>Nexaweb Platform v4.1</client-version> -->
<!-- <java-version>1.4.2</java-version> -->
<!-- <java-vendor>Sun Microsystems Inc.</java-vendor> -->
<!-- <os>Windows XP</os> -->
<!-- <os-version>5.1</os-version> -->
<!-- <browser>sun.plugin</browser> -->
<!-- <architecture>x86</architecture> -->
<!-- <user-agent>Mozilla/4.0 (compatible; MSIE 6.0; Windows NT )</user-agent> -->
<!-- <screen-size>1600,1200</screen-size> -->
<!-- <is-connection-secure>true</is-connection-secure> -->
<!-- <locale>en,US,</locale> -->
<!-- <is-connection-secure>false</is-connection-secure> -->
<!-- </client-info> -->
<!-- Example policies: -->
<!--
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.ThroughputFlushPolicy">
<flush-size>8 K</flush-size>
<measurement-period>10 sec.</measurement-period>
<minimum-throughput>4K</minimum-throughput>
</configuration>
</policy>
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodWithSizeThresholdFlushPolicy">
<flush-size>8 K</flush-size>
<period>10 sec.</period>
<message-size-threshold>200 bytes</message-size-threshold>
</configuration>
</policy>
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.4')" />
<match xpath="starts-with(/client-info/java-vendor, 'Sun')" />
<match xpath="contains(/client-info/user-agent, 'MSIE 6')" />
<match address="127.0.0.*" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodFlushPolicy">
<flush-size>8 K</flush-size>
<period>10 sec.</period>
</configuration>
</policy>
</push-connection-flush-policies>
-->
<!-- Default flush policy for Microsoft JVM -->
<!-- -->
<!-- Microsoft JVM causes the last push message to be buffered and not -->
<!-- available to the NexawebClient. This flush policy will generate -->
<!-- an empty message and flush the regular message out of the buffer -->
<!-- so that it can be processed. This should be adjusted to match the -->
<!-- use patterns of your application. -->
<policy>
<rules>
<match xpath="starts-with(/client-info/java-version, '1.1')" />
<match xpath="starts-with(/client-info/java-vendor, 'Microsoft')" />
</rules>
<configuration class="com.nexaweb.server.pushconnection.flushpolicies.IdlePeriodFlushPolicy">
<flush-size>5 K</flush-size>
<period>100 millis</period>
</configuration>
</policy>
</push-connection-flush-policies>
</configuration>
</default-session-configuration>
</session-configurations>
<!-- =================================================================== -->
<!-- Launch Configuration -->
<!-- =================================================================== -->
<!-- This section allows for the customization of the default Nexaweb -->
<!-- Client launch pages. If you have written your own launch pages, -->
<!-- these values will not have any effect on your application. -->
<!-- -->
<!-- Each of the values specified below may be overridden INDIVIDUALLY in -->
<!-- your application's local client.xml file. Thus, it is recommended -->
<!-- that you do NOT copy the entire section to override one value, but -->
<!-- rather just the value itself. -->
<!-- -->
<!-- Example: -->
<!-- -->
<!-- If you wished to override the applet width, you would place the -->
<!-- following XML in your client.xml file: -->
<!-- -->
<!-- <client-launch-configuration> -->
<!-- <applet-width>50%</applet-width> -->
<!-- </client-launch-configuration> -->
<!-- -->
<!-- There is no need to copy the entire section. In this way it will be -->
<!-- easy to figure out what you have customized and what you have not. -->
<launch-configuration>
<!-- The title of the browser window that displays the Nexaweb -->
<!-- application. -->
<window-title>Welcome To Nexaweb</window-title>
<!-- Parameters can be arbitrarily written into the client and read -->
<!-- back out through a client-side API. -->
<applet-parameters>
<!-- Example applet parameter name/value pair: -->
<!-- <param name="User Name" value="James Joyce" /> -->
</applet-parameters>
<!-- The start page of the Nexaweb application. The index.jsp file -->
<!-- will launch the application from this page. -->
<initial-page>java-index.xal</initial-page>
<!-- When true, the un-obfuscated Nexaweb client jars will be used. -->
<ui-test>false</ui-test>
<!-- Sets the type of application being run. The application type is -->
<!-- used to identify valid namespaces and root tags for XML documents. -->
<!-- Possible values -->
<!-- XAL - xal complient apps created with 4.5.1 or higher. -->
<!-- NXML - allow pre 4.5 syntax -->
<application-type>XAL</application-type>
<!-- When true, the jar containing the Nexaweb Foundation Classes -->
<!-- (NFC) will be written in the applet definition to make them -->
<!-- available for use on the client side. When false, the NFC -->
<!-- classes will not be written in the applet definition and NFC will -->
<!-- not be usable on the client side unless the jar is manually added -->
<!-- to the classpath. -->
<nfc>false</nfc>
<!-- When false, Nexaweb JvmDetector will continue to load the Nexaweb -->
<!-- client even if an unknown Jvm is detected. -->
<!-- -->
<!-- When true, Nexaweb JvmDetector will prompt to the user that the -->
<!-- JVM has not been tested and the user can choose to continue. -->
<display-unknown-vm-in-status>false</display-unknown-vm-in-status>
<!-- Timeout value for loading the Nexaweb client. The unit is minute. -->
<!-- If the client can't be loaded in this interval, timeout message -->
<!-- will be displayed on the screen. -->
<!-- -->
<!-- The default value is 3 which means 3 minutes. -->
<applet-load-timeout>3</applet-load-timeout>
<!-- The Applet class used to launch Nexaweb. Users should not need to -->
<!-- change this value. -->
<applet-class>com.nexaweb.client.launcher.DefaultJvmDetector.class</applet-class>
<!-- The launch-ui section allows users to customize the look of the -->
<!-- Nexaweb-loading screen. -->
<launch-ui>
<!-- After 4.2, do not change "class=" assignment -->
<progress-handler class="com.nexaweb.client.launcher.DefaultProgressHandler">
<!-- default: #FFFFFF -->
<background-color>#FFFFFF</background-color>
<!-- Passed to progress-handler; DefaultProgressHandler ignores. -->
<!-- <bar-color>#C0C0C0</bar-color> -->
<!-- default: empty -->
<image-path>classpath://com/nexaweb/client/launcher/images/empty.gif</image-path>
<!-- default: empty; DefaultProgressHandler only. -->
<bar-image-path>classpath://com/nexaweb/client/launcher/images/animated_start.gif</bar-image-path>
<!-- default: empty-->
<!-- <title>Launching Nexaweb Client</title> -->
<!-- default: auto generated like 4.1.0.3456 -->
<!-- <version></version> -->
<!-- default: empty -->
<display>Initializing...</display>
<!-- default: left; can also be "center" or "right"; since 4.2, -->
<!-- horizontal page element alignment, DefaultProgressHandler only.-->
<align>left</align>
<!-- default: SansSerif; since 4.2, font face used in page elements,-->
<!-- DefaultProgressHandler only. Logical fonts Serif, SansSerif, -->
<!-- Dialog, DialogInput, and Monospaced exist on all client -->
<!-- computers; physical fonts such as "Arial" may not. -->
<fontface>SansSerif</fontface>
<!-- shows a "more info" button in case JVM cannot be determined if true -->
<show-unknown-vm-status>true</show-unknown-vm-status>
</progress-handler>
</launch-ui>
<!-- Specify requirements needed to run the client. If these are not met
an error is displayed onscreen with a button that links to the error page. -->
<launch-requirements>
<jvm-version>
<!-- The client will display an error if the JVM being used
in not in the list of JVMs to include, or if it is in the list
of JVMs to exlcude. You can specify multiple include and
exclude tags. -->
<!-- '*' is a special character that means matches all. It can not
be used in any other sort of pattern matching. -->
<include>*</include>
<!-- Use exclude to exclude certain JVMs. -->
<!-- <exclude></exclude> -->
<!-- more examples: This example creates an app that will run with
any 1.4 JVM except 1.4.0 and also with 1.3.2_02
<include>1.4</include>
<include>1.3.2_02</include>
<exclude>1.4.0</exclude>
-->
</jvm-version>
<!-- Similar to jvm-version, you can include and exclude vendors.
The string in the include or exlude is checked to see if it
is contained in the "java.vendor" property. For example
"sun" would match against the Sun plug-in which reports
"Sun Microsystems" as the java.vendor-->
<jvm-vendor>
<include>*</include>
<!-- <exclude></exclude> -->
</jvm-vendor>
<!-- This matching is the same as jvm-version except that it checks
against the user-agent as reported by the web-browser. -->
<user-agent>
<include>*</include>
<!-- <exclude></exclude> -->
</user-agent>
<!-- Specifies the minimum screen resolution the client must have -->
<minimum-screen-resolution>
<width>0</width>
<height>0</height>
</minimum-screen-resolution>
<!-- If the client does not meet the launch requirements an error message
will appear with a button that links to the given page. Like other
Nexaweb error pages this page will be passed client information
as paramters in the URL string. The "exception" parameter will
indicate the reason the client did not meet launch requirements.
It will be one of:
jvm-version-not-included
jvm-version-excluded
jvm-vendor-not-included
jvm-vendor-excluded
user-agent-not-included
user-agent-excluded
minimum-screen-resolution-width
minimum-screen-resolution-height
-->
<error-page>Nexaweb/jsp/launcher/errorLaunchRequirementsNotMet.jsp</error-page>
</launch-requirements>
<!-- ======================================================== -->
<!-- These two values should not be modified by the user. -->
<applet-width>100%</applet-width>
<applet-height>100%</applet-height>
<launch-error-pages>
<!-- ====================================================== -->
<!-- The values here may be specified in one of three forms -->
<!-- 1 - Fully qualified URLs. These are recognized by -->
<!-- Nexaweb's code because they start with "http://"-->
<!-- or "https://". -->
<!-- 2 - Fully qualified URIs that include the web app -->
<!-- containing the error pages. These are -->
<!-- recognized by Nexaweb's code because the start -->
<!-- with a "/" character. -->
<!-- 3 - A path relative to your web application root. -->
<!-- All values that do not meet the criteria for -->
<!-- cases 1 and 2 will be treated as such. -->
<buggy-vm>Nexaweb/jsp/launcher/errorBuggyVM.jsp</buggy-vm>
<bad-vm>Nexaweb/jsp/launcher/errorBadVM.jsp</bad-vm>
<loading-timed-out>Nexaweb/jsp/launcher/errorLoadingTimedout.jsp</loading-timed-out>
<loading-failed>Nexaweb/jsp/launcher/errorLoadingFailed.jsp</loading-failed>
<starting-failed>Nexaweb/jsp/launcher/errorStartingFailed.jsp</starting-failed>
<delete-no-cab-cookie>Nexaweb/jsp/launcher/deleteNocabCookie.jsp</delete-no-cab-cookie>
</launch-error-pages>
<!-- =========================================================== -->
<!-- This boolean value determines whether or not the start page -->
<!-- will allow the "initialPage" URL parameter to override the -->
<!-- initial page specified in the configuration. This is often -->
<!-- set to true in a test or development environment, but will -->
<!-- likely be false in a production environment where a specific-->
<!-- workflow must be enforced. -->
<allow-url-parameter-for-initial-page>false</allow-url-parameter-for-initial-page>
<!-- ================================================== -->
<!-- This value is commented out because when the value -->
<!-- is NOT supplied here, each applet def written will -->
<!-- get a Unique ID. Use this value to customize the -->
<!-- ID of the applet written in order to address it in -->
<!-- javascript. -->
<!-- -->
<!-- To write more than one nexaweb applet on a page, -->
<!-- with known IDs instead of generated UIDs, you must -->
<!-- customize the writing of the applet tag. -->
<!-- <applet-id>custom-id</applet-id> -->
<!-- ================================================== -->
<!-- This value should be used when there is some -->
<!-- network hardware between the client and server -->
<!-- performing URL re-writing. Put the URL re-writer -->
<!-- context path here to ensure that the client's -->
<!-- requests are sent to the intervening hardware or -->
<!-- software with the correct context. -->
<!-- <context-path-override></context-path-override> -->
</launch-configuration>
<!-- =================================================================== -->
<!-- User-defined tag mapping files. -->
<!-- =================================================================== -->
<!-- This defines a set of configuration files used by the plug-in -->
<!-- architecture to map custom tag names in UI XML to tag-handling -->
<!-- implementation classes. See the documentation on the plug-in -->
<!-- architecture for details. -->
<client-tag-mapping>
<!-- Example tag mapping file definition: -->
<!-- <tag-map-file>Foo.map</tag-map-file> -->
</client-tag-mapping>
<!-- =================================================================== -->
<!-- Stylesheets. -->
<!-- =================================================================== -->
<!-- Defines at most one default stylesheet and any number of other -->
<!-- stylesheets that will be loaded on startup by the application. If no -->
<!-- default stylesheet is specified here "defaultstylesheet.txt" from -->
<!-- inside the client jar file is used. -->
<!-- -->
<!-- Example stylesheet declarations: -->
<!-- -->
<!--
<style-sheets>
<default-style-sheet>exampleSheet.xss</default-style-sheet>
<style-sheet>exampleSheet1.xss</style-sheet>
<style-sheet>exampleSheet2.xss</style-sheet>
</style-sheets>
-->
<style-sheets/>
<!-- =================================================================== -->
<!-- Client Log Settings -->
<!-- =================================================================== -->
<!-- default-log level specifies the default logging level for the -->
<!-- This can be overridden by individual log settings. -->
<log-configuration default-log-level="exception">
<!-- An example of specifying log level on an indvidual log -->
<!-- <log name="XModify" log-level="debug" /> -->
<consumers>
<!-- Be default two log consumers are included: one that logs all -->
<!-- messages to the console, and one that logs only error/exception -->
<!-- to a modal dialog. -->
<consumer class="com.nexaweb.util.ConsoleLogConsumer" />
<consumer class="com.nexaweb.client.log.DialogLogConsumer" />
</consumers>
</log-configuration>
<!-- =================================================================== -->
<!-- Tooltip delay setting (milliseconds) -->
<!-- =================================================================== -->
<tooltip-delay>500</tooltip-delay>
<!-- =================================================================== -->
<!-- Tab to radio groups -->
<!-- -->
<!-- Indicates whether or not to treat a group of radio buttons as -->
<!-- one tabbable component, so tabbing would occur to a set of radio -->
<!-- buttons and the arrow keys would be used to traverse the group. -->
<!-- -->
<!-- Possible settings: -->
<!-- true indicates to tab to the group, false (default) indicates -->
<!-- that the tab key should proceed through each radio button -->
<!-- individually. -->
<!-- =================================================================== -->
<tab-to-radio-groups>false</tab-to-radio-groups>
<!-- =================================================================== -->
<!-- Window deactivation policy -->
<!-- -->
<!-- Indicates what action to take when the main client frame is -->
<!-- deactivated, for example by clicking away from the browser window -->
<!-- to use another application. -->
<!-- -->
<!-- Possible settings: -->
<!-- release-focus -->
<!-- Unfocus the current focused component, and re-focus when the -->
<!-- window reactivates. This is the default behavior. -->
<!-- disable-cursor-blink -->
<!-- Stop the cursor from blinking, has no effect on the focus. -->
<!-- none -->
<!-- Take no action. -->
<!-- =================================================================== -->
<window-deactivation-policy>release-focus</window-deactivation-policy>
<!-- =================================================================== -->
<!-- Indicates whether or not to keep the last client event which was -->
<!-- fired. -->
<!-- This may be set to true if a legacy application requires the event -->
<!-- to remain in memory after an event fires. This will cause all -->
<!-- memory structures related to the event to be held until the next -->
<!-- event occurs, so it should be used with caution in applications -->
<!-- with large memory requirements. -->
<!-- =================================================================== -->
<keep-last-client-event>false</keep-last-client-event>
<!-- =================================================================== -->
<!-- Indicates whether or not to allow the client to call out to a -->
<!-- javascript method to open a new browser. This is used to overcome -->
<!-- an issue with the latest java plugin enhancements which opens the -->
<!-- new browser window behind the existing application window. -->
<!-- The default is "true". If there are issues in a supported browser -->
<!-- for a particular environment, this may be set to "false" which will -->
<!-- have the client use the applet's open browser call as was the -->
<!-- previous implementation. If any exception occurs attempting to make -->
<!-- the javascript call out, the applet's open browser call will be -->
<!-- used. -->
<!-- =================================================================== -->
<javascript-browser-open-enabled>true</javascript-browser-open-enabled>
<!-- =================================================================== -->
<!-- In multithreaded UI applications that require extra synchronization -->
<!-- on the server, set this to true to indicate that the client should -->
<!-- synchronize when constructing nexaweb server messages with requests -->
<!-- =================================================================== -->
<synchronize-nexaweb-server-requests>false</synchronize-nexaweb-server-requests>
<!-- =================================================================== -->
<!-- In multithreaded UI applications that use persistent connections, -->
<!-- this value indicates to open the push connection cleanly, ensuring -->
<!-- that there will be no possibility for timing issues transmitting -->
<!-- outbound client information to the server when a push connection -->
<!-- needs to re-establish. -->
<!-- It is not recommended to change this setting. -->
<!-- If synchronize-nexaweb-server-requests is set to true, this setting -->
<!-- will have no effect, and the push connection will ALWAYS be opened -->
<!-- without additional outbound protocol information, regardless. -->
<!-- =================================================================== -->
<open-push-without-protocol>true</open-push-without-protocol>
<!-- =================================================================== -->
<!-- Anti-aliasing -->
<!-- =================================================================== -->
<!-- The minimum font size to anti-alias. All label/button text of this -->
<!-- size or above will be rendered anti-aliased. -->
<anti-alias-minimum-font-size>18</anti-alias-minimum-font-size>
<!-- =================================================================== -->
<!-- Backwards compatibility settings -->
<!-- =================================================================== -->
<!-- Starting in 4.1, the HttpRequest will adjust the request method -->
<!-- internally unless user chooses to be backwards compatible with 4.0 -->
<!-- behavior. In 4.0, the request method is always false. -->
<is-http-request-4_0-compatible>false</is-http-request-4_0-compatible>
<!-- Starting in 4.1, pressing F1 or F2 will no longer print out the UI -->
<!-- DOM unless this setting is enabled. -->
<debug-keys-enabled>true</debug-keys-enabled>
<!-- Starting in 4.2, this can be set true to internally resignal -->
<!-- keyPress events incorrectly so that QuickTestPro will record them -->
<!-- correctly. Default is false. -->
<!-- NOTE: -->
<!-- Although this setting is still valid, there is now a patch -->
<!-- available from Mercury that addresses this issue. It is -->
<!-- recommended that you contact your Mercury representative -->
<!-- and request the patch. Refer to the platform documentation for -->
<!-- information on how to obtain the patch from Mercury. -->
<quick-test-pro-record-fix>false</quick-test-pro-record-fix>
<!-- Starting in 4.1, when an MCO event is called as an event handler -->
<!-- the glass pane is displayed without a wait cursor unless this -->
<!-- setting is enabled. -->
<display-wait-cursor-for-mco-calls>false</display-wait-cursor-for-mco-calls>
<!-- This parameter is supplied so that parsing of MCO string arguments can be -->
<!-- the same as in pre-4.2 versions. In 4.2 \" is converted to ", \\ is -->
<!-- converted to \, and \x where x is not a valid escape sequence is an -->
<!-- error. This is similar to the way strings are escaped in Java code. In 4.1 -->
<!-- \" is converted to " only. \\ is not converted to \ and freestanding \ -->
<!-- characters are allowed. -->
<ensure-pre-4-dot-2-mco-string-argument-compatibility>false</ensure-pre-4-dot-2-mco-string-argument-compatibility>
<!-- This parameter is supplied so that the macro code can know NOT -->
<!-- to use MessageFormat for the macro strings. in 4.2 we added parameters -->
<!-- which use MessageFormat, thus single tick escaping is required in 4.2 -->
<!-- plus. We want existing macros to work if the customer so desires. -->
<ensure-pre-4-dot-2-macro-compatibility>false</ensure-pre-4-dot-2-macro-compatibility>
<!-- This parameter is supplied so that the client can know NOT to -->
<!-- interpret {...} in attributes and text nodes as items needing -->
<!-- resolution. When this is set to true {...} is not interpreted in -->
<!-- in any way and { and } do not need to be escaped. -->
<ensure-pre-4-dot-2-resolution-syntax-compatibility>false</ensure-pre-4-dot-2-resolution-syntax-compatibility>
<!-- This parameter provides backwards compatibility support for customers which require -->
<!-- (count-on) the bug where a state change is reported on the client when the mouse is -->
<!-- pressed on a row or cell (or listItem in a listBox). When set to true the client -->
<!-- will always report an onStateChangeEvent when the mouse is pressed on a row or cell, -->
<!-- even when the state has not changed -->
<ensure-pre-bugfix-table-statechange-behavior-onmousedown>false</ensure-pre-bugfix-table-statechange-behavior-onmousedown>
<!-- This parameter is used so the XUpdate behavior can be the same as in pre-4.2 -->
<!-- versions. In pre 4.2 versions the root element of a Document is always used -->
<!-- as the context object when evaluating XUpdate directives. In 4.2 and later -->
<!-- the Document object is used as the context. -->
<use-root-element-as-context-instead-of-document>false</use-root-element-as-context-instead-of-document>
<!-- These two parameters are used in conjunction with automate test tools such -->
<!-- as Quick Test Pro. generate-unique-ids ensures that a unique test id can be retrieved -->
<!-- from the component and used for identification purposes. show-ancestors indicates -->
<!-- whether or not to include the names of the ancestors of the component, when generating the test id. -->
<!--
<testids>
<generate-unique-ids>true</generate-unique-ids>
<show-ancestors>false</show-ancestors>
</testids>
-->
<!-- This parameter enables using HTTP request header to store Nexaweb session id. When the -->
<!-- parameter is omitted or its value is false, the Nexaweb session id is sent in a cookie; when -->
<!-- true, the session id is sent in a request header X-NXSESSIONID. Some proxy severs may strip -->
<!-- non-standard request headers. When the header X-NXSESSIONID is not stripped, setting this -->
<!-- this parameter to true can be used for supporting multiple sessions per browser instance. -->
<!--
<use-http-request-header-for-session-id>true</use-http-request-header-for-session-id>
-->
<!-- This parameter provides an option to use Windows style for restoring windows i.e. using -->
<!-- restore button always restores back to normal window size. When the parameter is omitted or -->
<!-- its value is false, it will use unix style which restores windows to pre maximized state. -->
<!--
<windows-style-restore>true</windows-style-restore>
-->
<!-- This parameter provides backwards compatibility support for customers who want to be able to-->
<!-- use mousewheel to scroll bar in a disabled component. When the parameter is omitted or -->
<!-- its value is true, it will ignore mouse wheel event on disabled components. -->
<!--
<ignore-scrollWheelEvent-on-disabled>false</ignore-scrollWheelEvent-on-disabled>
-->
<!-- This parameter is used to define the quality of a upscaled or downscaled image. Value can be -->
<!-- either "high" or "low"; default value for both is low. When the value is set high for a -->
<!-- downscaled image, and the scale factor is more than two,in order to obtain a higher quality -->
<!-- image, we repeatedly scale the image by half till we've got the target image and save all -->
<!-- scaled image instances. Thus it require higher processing time and memory resource -->
<!--
<image-draw-policy>
<upscale-quality>low</upscale-quality>
<downscale-quality>low</downscale-quality>
</image-draw-policy>
-->
</client-app>