Orbeon Forms User Guide

XForms Reference: XForms Engine Configuration

1. Introduction

This part of the XForms reference documentation focuses on XForms engine configuration.

2. State Handling

2.1. Rationale

The Orbeon Forms XForms engine requires keeping processing state while operating on an XForms page. Such state includes the current values of XForms instances, selected repeated elements, and more. With Orbeon Forms, XForms state information can be handled in one of two ways:

  • Server-side: in this case, state information is stored on the server. Only very little state information circulates between client and server. The most frequently used state information is stored in memory. Less frequently used state information is stored on disk in a local database.

    Benefits of the approach:

    • Resulting HTML page are smaller. HTML pages increase in size as more XForms controls are used, but they don't increase in size proportionally to the size of XForms instances.

    • Small amounts of data circulate between the client browser and the Orbeon Forms XForms server.

    • This means that very large XForms instances can be processed without any impact on the amount of data that is transmitted between the client and the server.

    Drawbacks of the approach:

    • The Orbeon Forms XForms server needs to be stateful. It uses server memory to store state information even when no request is being processed. This creates additional demand for resources on the server and slightly complicates the task of tuning the server.

    • State information can become unavailable when sessions expire or when the server is restarted. When state information becomes unavailable for a page, that page will no longer function unless it is reloaded.

    Note
    Orbeon Forms ensures that it is possible to open multiple client browser windows showing the same page within the same session.
  • Client-side: in this case, static initial state information is sent along with the initial HTML page, and dynamic state is exchanged over the wire between the client browser and the Orbeon Forms XForms server when necessary.

    Benefits of the approach:

    • The Orbeon Forms server is entirely stateless. It only requires memory while processing a client request. It can be restarted without consequence for the XForms engine.

    • State information does not expire as long as the user keeps the application page open in the web browser.

    Drawbacks of the approach:

    • Resulting HTML pages are larger. In particular, the size of state data grows when XForms instances grow, regardless of whether many XForms controls are bound to instance data.

    • More data circulates between the client browser and the Orbeon Forms XForms server.

    Note
    Orbeon Forms compresses and encrypts XForms state information sent to the client.

By default, Orbeon forms store XForms state information on the server. Please change this default to client-side only if you have well understood the tradeoffs explained above.

2.2. Configuring State Handling

State handling can be configured globally for all pages, or locally for each individual page served. Global configuration is performed in properties.xml with the oxf.xforms.state-handling property. When missing or set to client, state is stored client-side. When set to server, state is stored server-side. For example:

<!-- Store state on the server --><property as="xs:string" name="oxf.xforms.state-handling" value="server"/>

The global configuration can be overridden for each page by setting the xxforms:state-handling attribute in the page. This attribute can be set on the root element of the XHTML page, or on the first xforms:model element. Only the first such attribute encountered by the XForms engine is used:

<xforms:model xxforms:state-handling="client">...</xforms:model>

When storing state on the server, the maximum size of the data to be stored globally in memory can be selected using the oxf.xforms.store.application.size property. The size is specified in bytes:

<!-- Allow a maximum of 20 MB of state information among all users --><property as="xs:integer" name="oxf.xforms.store.application.size" value="20000000"/>

When the allowed memory space for state information is full, Orbeon passivates state information to a local eXist database. Configuration parameters for the connection to the eXist database can be changed. The defaults are as follows:

<!-- Disk-based store connection information --><property as="xs:string" name="oxf.xforms.store.application.username" value="guest"/><property as="xs:string" name="oxf.xforms.store.application.password" value="guest"/><property as="xs:anyURI" name="oxf.xforms.store.application.uri" value="xmldb:exist:///"/><property as="xs:string" name="oxf.xforms.store.application.collection" value="/db/orbeon/xforms/cache/"/>

Whether state information is kept client-side or server-side, a property controls whether the XForms engine should try to optimize state reconstruction by using a cache. This property should usually be set to true:

<!-- This should usually be set to "true" --><property as="xs:boolean" name="oxf.xforms.cache.document" value="true"/>

If the above property is set to true, the number of XForms documents that can be held in that document cache at a given time is configured with the following property:

<!-- Store at most 10 documents in the cache --><property as="xs:integer" name="oxf.xforms.cache.documents.size" value="10"/>

Note that this represents XForms documents in a particular state of interaction with a user, which means that if to users load the same XForms page two entries will be needed in the cache.

2.3. Session Heartbeat

If you happen to leave a browser window open on your computer, chances are that you will get back to that window and keep using the application. The last thing you want to happen when you come back is lose your session and therefore your data.

This is not always a correct guess of course: you may just happen to leave a window or tab open without planning to use it again. Conversely you may have a page which is not actually visible, for example in your browser history, yet you will come back to it. This approach wouldn???t be good for banking applications either. Still, in many situations, such as filling-out large forms, it sounds like a good idea to keep your session alive for open pages.

To achieve this goal you could make all server sessions longer. However this is harder to configure for the application developer, and this won???t discriminate between pages that are actually open on a client and the ones that are not. And while it may be ideal to have infinitely long sessions, unfortunately many applications are not ready for this kind of approach.

So Orbeon Forms supports a "session heartbeat" feature. Here is how this works:

  • When this feature is enabled (the default), an open XForms page in a client browser regularly pings the server through Ajax to keep the current server session alive.

  • The ping delay is automatically computed based on the server???s session timeout. The client pings the server at 80% of the session expiration time after the last interaction with the server.

  • We are careful not to hit the XForms engine too much, in fact we do a very limited amount of work on the server for each ping, so they should run fast.

  • XForms state information for pages hit with the heartbeat just migrates to the disk store over time if RAM is used by other pages, so keeping even large numbers of pages open should not have any negative impact on server RAM.

  • When a user gets back to using the page, state information migrates back from disk to RAM, and the page will be live again.

  • Sessions do eventually expire as nobody keeps a browser open forever.

Note that whenever an application keeps sessions alive for a long time, it is a good idea to keep as little data as possible in the session. The Orbeon Forms XForms engine itself uses a global state store and does not use session objects for storage, but do remember to keep your sessions small!

The session heartbeat should help prevent many occurrences of "session expired" error messages. As an Orbeon Forms application developer you don???t have to worry about anything: the session heartbeat is enabled by default. You can configure it globally in properties.xml:

<property as="xs:boolean" name="oxf.xforms.session-heartbeat" value="true"/>

You can also override the global default by specifying a property on the first XForms model of a page:

<xforms:model id="my-model" xxforms:session-heartbeat="false"/>

3. Local Submissions

3.1. Rationale

XForms pages can make heavy use of services through the use of <xforms:submission>. A service is primarily identified by a URL.

  • Sometimes a service is remote (on a machine other than the machine on which Orbeon Forms is installed), in which case the URL is necessarily an absolute URL starting with http:// or https://.

  • But often services are implemented within Orbeon Forms itself, not only on the same server but within the same web application. In the case of such local submission, Orbeon Forms provides a special optimized mode which has the following benefits:

    • No actual HTTP connection is initiated, so performance is likely to be better.

    • There is no need to deal with absolute URLs such as http://localhost:8080, especially when proxies or firewalls are in place.

For more information, see also the Configuration Properties related to submissions.

3.2. Enabling Local Submissions

Orbeon Forms performs a local submission if:

  • The URL specified is not a absolute, i.e. does not start with http:// or https://.

  • The submission is not asynchronous. (This restriction may be lifted in the future.)

  • In a servlet environment:

    • The submission has replace="all" (which is the default if no replace attribute is specified) and the oxf.xforms.oxf.xforms.local-submission-forward property is set to true (which is the default).

    • The submission has replace="instance", replace="text" or replace="none" and the oxf.xforms.oxf.xforms.local-submission-include property is set to true (the default is false).

  • In a portlet environment:

    • The f:url-norewrite attribute is not set to true.

    • The f:url-type attribute is not set to resource.

    Note
    The portlet logic above is likely to be revised in the future. Also note that in the case of optimized submissions within portlets, requests are made directly to the Orbeon Forms portlet and do not use servlet forward/include.

3.3. Context Resolution

In a servlet environment, paths are resolved as follows:

  • If f:url-norewrite is not set to true, the resource is resolved against the current servlet context.

  • If f:url-norewrite is set to true, the resource is resolved against the servlet container root. This allows accessing other web applications within the same servlet container.

Say your application is under context /orbeon, and you have a second web application under context /foo:

<!-- This submission calls /orbeon/bar --><xforms:submission replace="all" method="post" resource="/bar"/><!-- This submission calls /foo/bar --><xforms:submission replace="all" method="post" resource="/foo/bar" f:url-norewrite="true"/>

3.4. Limitations of Includes

With replace="instance", replace="text" or replace="none", optimized submission are implemented using the servlet container's include mechanism, which does not automatically build path information for the included resource.

In this case, Orbeon Forms is therefore unable to provide proper "servlet path" and "path info" information. Orbeon Forms handles this situation in the following way:

  • A blank ("") "servlet path" is provided.

  • The "path info" contains the entire path provided, instead of the path following the servlet path.

This may cause some application which rely on the "servlet path" information to behave incorrectly. For example, consider the eXist REST servlet:

  • It is mounted as /exist/rest within Orbeon Forms.

  • eXist (quite properly) expects any path following /exist/rest to be a path into the database, e.g. /exist/rest/db/orbeon produces a path called /db/orbeon.

  • If Orbeon Forms calls the eXist REST servlet with a blank servlet path and a path info containing /exist/rest/db/orbeon, eXist obviously obtains an incorrect database path.

Warning
In short you must be careful when using local includes. The good news is that if you are using servlets which do not depend on path information as explained above, or if you have control over the implementation of the services you are calling, then you can most likely work around this limitation.

Local forwards are not subject to that limitation.

4. JavaScript and CSS Resources

4.1. Minimal Resources

Most JavaScript and CSS files used by the XForms engine are available in two versions:

  • A full version, which may contain comments, spaces, longer identifiers, etc.

  • A minimal version, which is usually much smaller

Both versions work exactly the same. For development and debugging of the XForms engine itself, the full version is easier to work with. But if you never work directly with these JavaScript and CSS files, as well as for deployment, the minimal versions are recommended as they will load faster in the user's web browser. You enable minimal resources in properties.xml as follows:

<!-- Enable minimal resources --><property as="xs:boolean" name="oxf.xforms.minimal-resources" value="true"/>

4.2. Combined Resources

Serving CSS and JavaScript can have a high performance cost on page loads. This is particularly important with the intensive use of JavaScript in Orbeon Forms. In particular, it can be shown that serving many small files is slower than serving a single large file. In theory, HTTP pipelining can improve very much on this, but this is (very unfortunately) useless in practice at the time of writing because Internet Explorer doesn't implement it at all and Firefox / Mozilla do implemente it but do not enable it by default. This is why Orbeon Forms supports the option of combining the multiple JavaScript and CSS files required for a given XForms page into a single JavaScript file and a single CSS file.

You enable this feature in properties.xml as follows

<!-- Enable combined resources --><property as="xs:boolean" name="oxf.xforms.combined-resources" value="true"/>

When this is enabled, Orbeon Forms refers to a single JavaScript file and a single CSS file for XForms-related functionality. The URL identifies special resources needed by the page, for example:

<link rel="stylesheet" href="/ops/xforms-server/xforms-range-autocomplete-min.css" type="text/css"/><script type="text/javascript" src="/ops/xforms-server/xforms-range-autocomplete-min.js"/>

This in short tells the XForms server to produce the minimal CSS and JavaScript for the XForms engine including support for the "range" and "autocomplete" features. Note that you don't have to write these URLs yourself: the Orbeon Forms XForms engine adds them automatically to your page.

When the Orbeon Forms XForms server receives a request for a combined resource, it determine what files need to be combined and outputs them all together. Furthmore, for CSS files, all URLs referred to with url() are rewritten, so that links to images, in particular, remain correct.

In addition, you can enable caching of combined resources with:

<!-- Enable caching of combined resources --><property as="xs:boolean" name="oxf.xforms.cache-combined-resources" value="true"/>

This cache works differently from other Orbeon Forms caches, as the result is stored in the resources, typically under:

WEB-INF/resources/xforms-server/

One benefit of this mechanism is that it allows making such combined files to be served by an Apache front-end.

4.3. Versioned Resources

To further improve caching efficiency, Orbeon Forms supports enabling versioned resources. Usually, a resource such as a CSS, JavaScript or image file, is served through URLs like this one:

http://localhost:8080/orbeon/xforms-server/xforms-dialog-min.js

When configuring caching on the server, for example by using an Apache front-end, you may face a dilemma:

  • Caching aggressively (with an expiration date far in the future and no revalidation) so that the client asks for the resource as rarely as possible. Doing so may cause resources on the client to be out of date.

  • Caching for a shorter period of time or by forcing revalidation so that your client always has a fresh version of the resources. Doing so may cause longer page loads and more load on the server.

Orbeon Forms solves this by providing the option of using versioned resources, that is inserting automatically a version number within resource URLs. You enable versioned resources in properties.xml:

<property as="xs:boolean" name="oxf.resources.versioned" value="true"/>

With this, the resource above is served as follows:

http://localhost:8080/orbeon/xforms-server/3.6.0.200803010236/xforms-dialog-min.js

The XForms Server component, which serves the resource in this case, sets an expiration date far in the future. For example, this is the description of the cache entry in the Firefox about:cache page:

          Key: http://localhost:8080/orbeon/xforms-server/3.6.0.200803010236/xforms-dialog-min.css
    Data size: 22524 bytes
  Fetch count: 2
Last modified: 2008-03-01 17:04:25
      Expires: 2011-12-25 17:10:42

This means that the resource can effectively be cached "for ever" by a client. In case the client visits Orbeon Forms pages often, the resources will be availabe from cache, therefore reducing page loading times and server load as well.

When Orbeon Forms is upgraded on the server, the version number changes as well. An XForms page will refer to resources with the new version number, so the cached resource is not used by the browser and a new resource is loaded from the server, before being cached. This "magic" is enabled simply with the inclusion of the Orbeon Forms version number in the URL.

Only CSS and JavaScript resources used by the XForms engine are loaded through the XForms Server component. Other resources like images referred by XForms stylesheets are served by the Page Flow Controller, through URLs like this one:

http://localhost:8080/orbeon/ops/images/xforms/error.gif

With resource versioning enabled, the URL becomes:

http://localhost:8080/orbeon/3.6.0.200803010236/ops/images/xforms/error.gif

When resource versioning is enabled, the Page Flow Controller by default serves all the resources defined in <files> elements by first checking the oxf.resources.versioned property. If versioning is enabled, the PFC removes the version number from the URL before searching for the resource on disk. It is possible to turn this behavior on and off selectively with the versioned attribute. Here is how to turn off versioning for PDF files in page-flow.xml:

<config xmlns:oxf="http://www.orbeon.com/oxf/processors" xmlns="http://www.orbeon.com/oxf/controller"><!-- GIF images are loaded following oxf.resources.versioned --><files path-info="*.gif"/><!-- More file definitions here -->...<!-- PDF files are not versioned --><files path-info="*.pdf" versioned="false"/><!-- More file definitions here -->...<!-- More page definitions here -->...</config>

Conversely, resource URLs produced by an XForms page are automatically rewritten following the Page Flow's <files> definitions.

The versioning mechanism is made available to your own application resources as well. Any resource whose path doesn't start with /ops/ or /config/ is considered part of your application, not of Orbeon Forms. In that case, the Orbeon Forms version number is not used, but you specify instead an application version number in properties.xml:

<property as="xs:string" name="oxf.resources.version-number" value="1.6.3"/>

Note that if this property is commented out or missing, no versioning takes place for your application resources even if oxf.resources.versioned is set to true.

For deployed application, you should upgrade the application version number whenever you modify application resources so that clients retrieve the proper resources.

The following scenario shows the entire lifecycle for application resources:

  • You an image as RESOURCES/apps/foo/bar.png

  • You refer to it as:

    <xhtml:body><xhtml:img src="/apps/foo/bar.png" alt="My Image"/></xhtml:body>
  • With versioning enabled, the image path is rewritten automatically as follows:

    /1.6.3/apps/foo/bar.png

    Note that the application resource number is used because the resource is not part of Orbeon Forms.

  • Your browser sees a URL like:

    http://localhost:8080/orbeon/1.6.3/apps/foo/bar.png
  • When the browser loads the image, the PFC receives back:

    /1.6.3/apps/foo/bar.png
  • The PFC knows that PNG files are versioned, so removes the version number and sends this resource to the browser:

    RESOURCES/apps/foo/bar.png

From client-side JavaScript, you can access the application version number as follow:

var version = ORBEON.util.Utils.getProperty(APPLICATION_RESOURCES_VERSION_PROPERTY);

At the moment, the resources served by the PFC (that is all the resources except the XForms engine's CSS and JavaScript resources) do not automatically get a special expiration date. If you want to fully leverage client-side caching capabilities, you may want to use an Apache front-end or a Servlet filter to modify the Expires header of those resources. With Apache, you can use mod_expires.

In case you use Apache, you can in addition configure a rewriting rule with mod_rewrite to allow Apache to directly load resources containing a version number, as shown below.

Note

We recommend restarting Orbeon Forms after changing the oxf.resources.versioned property, as data in Orbeon Forms caches may not be made aware of the change until the next restart.

4.4. Examples of Apache Configurations

Here is how you can configure Apache to serve Orbeon Forms resources. This assumes the following:

  • Orbeon Forms deployed under the /orbeon context

  • Orbeon Forms exploded WAR file under /home/orbeon/war/

  • orbeon-resources-public.jar unziped under /home/orbeon/war/WEB-INF/orbeon-resources-public/

  • oxf.xforms.cache-combined-resources set to true in properties.xml

Without resources versioning:

RewriteEngine on
# Rewrite CSS and JavaScript resources served by the XForms Server
# -> make sure "oxf.xforms.cache-combined-resources" is set to "true" in properties.xml
RewriteRule ^/orbeon/(xforms-server/.*\.(css|js))$ /home/orbeon/war/WEB-INF/resources/$1 [L]
# Serve /config/theme resources
# -> make sure orbeon-resources-public.jar is unzipped under "orbeon-resources-public"
RewriteRule ^/orbeon/(config/theme/.*\.(css|png|gif))$ /home/orbeon/war/WEB-INF/orbeon-resources-public/$1 [L]
# Special handling of PNG images for IE 6
RewriteCond %{HTTP_USER_AGENT} .*MSIE\ 6.*
# Make sure the corresponding GIF image exists
RewriteCond /home/orbeon/war/WEB-INF/orbeon-resources-public/$1.gif -f
# Match on PNG images only and rewrite to GIF
RewriteRule ^/orbeon/((ops|config/theme|xbl/orbeon)/.*)\.png$ /home/orbeon/war/WEB-INF/orbeon-resources-public/$1.gif [L]
# Serve /ops resources
# -> make sure orbeon-resources-public.jar is unzipped under "orbeon-resources-public"
RewriteRule ^/orbeon/((ops|config/theme|xbl/orbeon)/.*\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf))$ /home/orbeon/war/WEB-INF/orbeon-resources-public/$1 [L]
# Special handling of PNG images for IE 6
RewriteCond %{HTTP_USER_AGENT} .*MSIE\ 6.*
# Make sure the corresponding GIF image exists
RewriteCond /home/orbeon/war/WEB-INF/resources/$1.gif -f
# Match on PNG images only and rewrite to GIF
RewriteRule ^/orbeon/(.*)\.png$ /home/orbeon/war/WEB-INF/resources/$1.gif [L]
# Serve remaining resources
RewriteRule ^/orbeon/(.*\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf))$ /home/orbeon/war/WEB-INF/resources/$1 [L]

With resources versioning:

RewriteEngine on
# Rewrite CSS and JavaScript resources served by the XForms Server
# -> make sure "oxf.xforms.cache-combined-resources" is set to "true" in properties.xml
RewriteRule ^/orbeon/xforms-server/[^/]+/(.*\.(css|js))$ /home/orbeon/war/WEB-INF/resources/xforms-server/$1 [L]
# Special handling of PNG images for IE 6
RewriteCond %{HTTP_USER_AGENT} .*MSIE\ 6.*
# Make sure the corresponding GIF image exists
RewriteCond /home/orbeon/war/WEB-INF/orbeon-resources-public/$1.gif -f
# Match on PNG images only and rewrite to GIF
RewriteRule ^/orbeon/[^/]+/((ops|config/theme|xbl/orbeon)/.*)\.png$ /home/orbeon/war/WEB-INF/orbeon-resources-public/$1.gif [L]
# Serve /ops resources
# -> make sure orbeon-resources-public.jar is unzipped under "orbeon-resources-public"
RewriteRule ^/orbeon/[^/]+/((ops|config/theme|xbl/orbeon)/.*\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf))$ /home/orbeon/war/WEB-INF/orbeon-resources-public/$1 [L]
# Special handling of PNG images for IE 6
RewriteCond %{HTTP_USER_AGENT} .*MSIE\ 6.*
# Make sure the corresponding GIF image exists
RewriteCond /home/orbeon/war/WEB-INF/resources/$1.gif -f
# Match on PNG images only and rewrite to GIF
RewriteRule ^/orbeon/[^/]+/(.*)\.png$ /home/orbeon/war/WEB-INF/resources/$1.gif [L]
# Serve remaining resources
RewriteRule ^/orbeon/[^/]+/(.*\.(gif|css|pdf|json|js|png|jpg|xsd|htc|ico|swf))$ /home/orbeon/war/WEB-INF/resources/$1 [L]
Note

The rewriting rules above have special handling of PNG images for IE 6: when that browser is detected, any request for PNG image having a corresponding GIF image serves the GIF images instead. If you don't need that behavior, remove the corresponding lines in the rules above.

All in all, the rules above perform the following:

  • Special handling for XForms JavaScript and CSS files (using the cached/combined/minimized resources)
  • Serving of /config/theme resources originally in orbeon-resources-public.jar
  • Special handling of PNG images for IE 6 for /ops resources originally in orbeon-resources-public.jar
  • Serving of other /ops resources originally in orbeon-resources-public.jar
  • Special handling of PNG images for IE 6 for resources under RESOURCES
  • Serving of other resources under RESOURCES

5. Browser Navigation (Back and Forward) Handling

When visiting an XForms page by using your browser's Back and Forward buttons, or other browser-history mechanisms, Orbeon Forms by default restores the appearance of that page as it was when you left it. (Browsers don't automatically handle this behavior with Ajax applications!) This behavior best matches the usual user experience obtained when navigating regular web pages.

In certain situations, it can be useful instead to ask the XForms page to reload entirely. You control this by using the xxforms:revisit-handling attribute on the first XForms model of the page you want to reload. This attribute supports two values: restore (the default) and reload. Example:

<xforms:model xxforms:revisit-handling="reload"/>
Note
It is recommended to use the reload value carefully, as reloading pages upon browser navigation often does not match the expectation of the user.

6. Encryption

Orbeon Forms encrypt some information sent to the client (for example when using client-side state state handling). This is done through the following property in properties.xml:

<property as="xs:string" name="oxf.xforms.password" value="REPLACE THIS WITH YOUR OWN PASSWORD"/>
Warning

It is strongly advised to change the default password in the property above.

In addition, Orbeon Forms by default encrypts the value of selection controls before sending them to the client. This can be controlled with this property:

<property as="xs:boolean" name="oxf.xforms.encrypt-item-values" value="true"/>

In general, this should be set to true, but you can set it to false if you need to access the value of selection controls through JavaScript on the client, or through offline binds.

7. Debugging XForms Pages

7.1. Enabling XForms Logging

When a fatal error occurs, the XForms engine throws a Java exception which either results in an error page in your web browser (when the error occurrs during page initialization) or in an error message at the top of the displayed XForms page (when the error occurs during an Ajax request after the page is loaded). The main Java exception is also logged on the server.

Sometimes, this provides enough information to the developer to figure out what went wrong. But often this is not sufficient. The best tool available is the XForms engine logging facility. To enable it, make sure you uncomment the following lines in config/log4j.xml:

<category name="org.orbeon.oxf.xforms.processor.XFormsServer"><priority value="debug"/></category><category name="org.orbeon.oxf.xforms.processor.XFormsModelSubmission"><priority value="debug"/></category>
Note

You must restart your Servlet container for those changes to be taken into account.

These settings enable verbose logging of the XForms engine's operations, in particular:

  • Dispatching of events.

  • Execution of actions.

  • Loading of instances.

  • Execution of submissions.

  • Resulting XForms instances.

  • XForms cache-related operations.

The following shows a sample XForms logging session:

event - dispatching {name: "DOMFocusIn", id: "xf-222", location: "line 28 of XFormsDOMFocusInEvent.java"}
  action - executing {action name: "setvalue"}
setvalue - setting instance value {value: "4", instance: "fr-form-instance"}
event - dispatching {name: "xforms-recalculate", id: "fr-form-model", location: "line 1895 of XFormsModel.java"}
  model - performing recalculate {model id: "fr-form-model"}
  model - done recalculating {time: "4"}
event - dispatching {name: "xforms-revalidate", id: "fr-form-model", location: "line 1900 of XFormsModel.java"}
  model - performing revalidate {model id: "fr-form-model"}
  model - done rebuilding {model id: "fr-form-model", time: "1"}
event - dispatching {name: "xforms-refresh", id: "fr-form-model", location: "line 1905 of XFormsModel.java"}
  model - performing refresh {model id: "fr-form-model"}
  controls - start building
    model - evaluated variables {count: "1"}
  controls - end building {time (ms): "22"}
  event - dispatching {name: "xforms-value-changed", id: "xf-222", location: "line 27 of XFormsValueChangeEvent.java"}
    action - executing {action name: "setvalue"}
      setvalue - setting instance value {value: "dirty", instance: "fr-persistence-instance"}
  event - dispatching {name: "xforms-valid", id: "xf-222", location: "line 27 of XFormsValidEvent.java"}
event - dispatching {name: "xforms-recalculate", id: "fr-persistence-model", location: "line 1895 of XFormsModel.java"}
  model - performing recalculate {model id: "fr-persistence-model"}
  model - done recalculating {time: "5"}
event - dispatching {name: "xforms-revalidate", id: "fr-persistence-model", location: "line 1900 of XFormsModel.java"}
  model - performing revalidate {model id: "fr-persistence-model"}
  model - done rebuilding {model id: "fr-persistence-model", time: "5"}
event - dispatching {name: "xforms-refresh", id: "fr-persistence-model", location: "line 1905 of XFormsModel.java"}
  model - performing refresh {model id: "fr-persistence-model"}
  controls - start building
    model - evaluated variables {count: "1"}
  controls - end building {time (ms): "9"}
  event - dispatching {name: "xforms-value-changed", id: "fr-data-status-input", location: "line 27 of XFormsValueChangeEvent.java"}
  event - dispatching {name: "xforms-valid", id: "fr-data-status-input", location: "line 27 of XFormsValidEvent.java"}
controls - evaluating controls
controls - done evaluating controls {time (ms): "4"}

7.2. The Instance Inspector

The Instance Inspector allows you to visualize all the instances of your XForms page. You enable it by adding the following within your XForms page's xhtml:body element, typically just before closing that element:

<xhtml:body>...<widget:xforms-instance-inspector xmlns:widget="http://orbeon.org/oxf/xml/widget"/></xhtml:body>

This is an example of how the Instance Inspector looks like in your page:

You can select which model and instand to view, and decide whether to see plain XML or formatted XML.