Detail page

Children pages
​Attachments​
​Email​
​PDF​
HTML page layout
[SINCE Orbeon Forms 2019.2]
Available modes:
fixed (default)
fluid
When in fluid mode, the form sections and grids take the entire web browser's viewport size. This also applies when using the wizard view.
This can also be configured for a particular form in Form Builder's Form Settings dialog.
<property
    as="xs:string"
    name="oxf.fr.detail.html-page-layout.*.*"
    value="fixed"/>
Adding your own CSS files
[SINCE Orbeon Forms 2017.1]
In addition to oxf.fr.css.custom.uri, you can also use the following property, which apply only to the Detail page:
<property as="xs:string" name="oxf.fr.detail.css.custom.uri.*.*">
    /forms/acme/assets/acme-detail.css"
</property>
See also Adding your own CSS.
Adding your own JavaScript files
[SINCE Orbeon Forms 2017.1]
In addition to oxf.fr.js.custom.uri, you can also use the following property, which apply only to the Detail page:
<property as="xs:string" name="oxf.fr.detail.js.custom.uri.*.*">
    /forms/acme/assets/acme-detail.js"
</property>
See also Adding your own JavaScript.
Table of contents
Introduction
The table of contents is a list of sections in the form. It is shown at the top or left of the form, and allows users to navigate to a particular section.
Note the following:
The following configuration properties only relate to the use of the table of contents when the Wizard view is not used.
When using the Wizard view, a table of contents is handled by the Wizard itself and the global Table of Contents discussed here is disabled.
In View and PDF modes, the Wizard view is never in use.
Show table of contents
[SINCE Orbeon Forms 2023.1]
<property
    as="xs:integer"
    name="oxf.fr.detail.toc.min-sections.*.*"
    value="0"/>
If the number of table of contents entries (that is, of form sections) is greater than this value, then show the Table of Contents at the top of the form.
This can be omitted or set to -1 to never show the TOC.
[DEPRECATED SINCE Orbeon Forms 2023.1]
The following property does the same as oxf.fr.detail.toc.min-sections but is deprecated. Use oxf.fr.detail.toc.min-sections instead since Orbeon Forms 2023.1.
<property
    as="xs:integer"
    name="oxf.fr.detail.toc.*.*"
    value="0"/>
Position of the table of contents
[SINCE Orbeon Forms 2023.1]
<property
    as="xs:string"
    name="oxf.fr.detail.toc.position.*.*"
    value="top"/>
Where to place the table of contents: top, left, or none. The default is top. If neither top nor left is specified, the table of contents is not shown.
In PDF mode, the left position is not supported and the table of contents is always shown at the top.
Modes in which the table of contents is shown
[SINCE Orbeon Forms 2023.1]
<property
    as="xs:string"
    name="oxf.fr.detail.toc.modes.*.*"
    value="new edit"/>
The table of contents is shown in the specified modes only. The default is new edit view. The following modes are available: new, edit, view, pdf, tiff.
Position of error summary
<property
    as="xs:string"
    name="oxf.fr.detail.error-summary.*.*"
    value="bottom"/>
Where to place the error summary: top, bottom, both, or none.
Buttons on the Detail Page
Choosing which buttons are shown
<property
    as="xs:string"
    name="oxf.fr.detail.buttons.*.*"
    value="close clear print pdf save submit"/>
The property configures which buttons are included on the Detail Page, and in what order they are shown. For more information, see Buttons and Processes.
Hiding and disabling buttons
[SINCE Orbeon Forms 2016.2]
The following properties, where you replace BUTTON by a specific button name, control whether a particular button is visible (button visibility) or disabled (or "readonly"):
oxf.fr.detail.button.BUTTON.visible.*.*
oxf.fr.detail.button.BUTTON.enabled.*.*
The value of these properties is an XPath expression. For example the following properties hide, show, and disable buttons depending on whether the wizard shows its table of contents or its body (as of Orbeon Forms 2022.1):
  <property as="xs:string"  name="oxf.fr.detail.button.wizard-prev.visible.*.*"               >
      fr:owns-lease-or-none-required() and fr:is-wizard-body-shown()
  </property>
  <property as="xs:string"  name="oxf.fr.detail.button.wizard-prev.enabled.*.*">
      not(fr:is-wizard-first-page())
  </property>
  <property as="xs:string"  name="oxf.fr.detail.button.wizard-next.visible.*.*">
      fr:owns-lease-or-none-required() and fr:is-wizard-body-shown()
  </property>
  <property as="xs:string"  name="oxf.fr.detail.button.wizard-next.enabled.*.*">
      not(fr:is-wizard-last-page())
  </property>
  <property as="xs:string"  name="oxf.fr.detail.button.wizard-toc.visible.*.*">
      fr:owns-lease-or-none-required() and fr:is-wizard-separate-toc() and fr:is-wizard-body-shown()
  </property>
You can access control values in the data in one of two ways, where foo is the name of the control:
Use an expression of the type //foo. Note that control elements might not be unique in case of repeats or section templates, and so this returns as many XML elements as there are values in the data, including within repeats and within section templates.
Use fr:control-string-value('foo'). This only works for controls that are not in a section template and returns zero or one value. If the control is repeated, only the first value is returned.
NOTE: It's not yet possible to use the variable notation $foo.
Example searching data elements:
<property as="xs:string"  name="oxf.fr.detail.button.save-final.visible.*.*">
    xxf:non-blank(//foo)
</property>
Example with fr:control-string-value():
<property as="xs:string"  name="oxf.fr.detail.button.save-final.visible.*.*">
    xxf:non-blank(fr:control-string-value('foo'))
</property>
Loading indicator for buttons
[SINCE Orbeon Forms 2016.1]
The property oxf.fr.detail.loading-indicator.BUTTON.*.*, where you replace BUTTON by a specific button name, allows you to configure which loading indicator, if any, is to be used for that button. The value of the property can be either:
Empty, which is the default, and means "no loading indicator".
modal, greys out the background, shows a spinner in the center of the screen, and prevents any user input as long as the action triggered by the button is being processed.
inline, shows a spinner inside the button itself.
In the following example, the send button is made modal:
<property 
    as="xs:string"  
    name="oxf.fr.detail.loading-indicator.send.*.*"                 
    value="modal"/>
In general, we would expect this property to be used as follows:
modal for buttons performing actions for which allowing users to change the value of fields after the button is pressed wouldn't make any sense, would be confusing, or outright dangerous. This would for instance be the case for submit or publish buttons.
inline for buttons performing actions that are expected to take a little bit of time, like a save operation.
Empty for any other button.
In all cases, should an action take any noticeable amount of time, Orbeon Forms will always show a loading bar at the top of the page, so users know one of their actions is being processed.
By default, as shown in the below video:
The modal loading indicator used for the submit button.
The inline loading indicator for the save buttons (save-draft (up to 2020.1.x), save-progress (2021.1 and newer), and save-final).
Loading indicators
Controlling the appearance of control labels
[SINCE Orbeon Forms 2016.2]
By default, with Form Runner, control labels appear inline above the control. The following property allows overriding this behavior:
<property
    as="xs:string"
    name="oxf.xforms.label.appearance.*.*"
    value="full"/>
Allowed values:
full: labels show inline above the control (the default)
full minimal: labels show inline above the control, but for text, date, and time input fields only, labels show as an HTML placeholder within the field when the field is empty
LIMITATION: The minimal appearance is not supported on combined "Date and Time" fields and on text fields with "Character Counter" appearance.
NOTE: Only one minimal appearance can be used between oxf.xforms.label.appearance and oxf.xforms.hint.appearance. If both include minimal, the label wins.
For more about placeholders, see Use HTML5 placeholders, in XForms.
Controlling the appearance of control hints
[SINCE Orbeon Forms 2016.2]
By default, with Form Runner, control hints appear inline under the control. The following property allows overriding this behavior:
<property
    as="xs:string"
    name="oxf.xforms.hint.appearance.*.*"
    value="full"/>
Allowed values:
full: hints show inline below the control (the default)
full minimal: hints show inline below the control, but for text, date, and time input fields only, hints show as an HTML placeholder within the field when the field is empty
tooltip: hints show as tooltips upon mouseover
tooltip minimal: hints show as tooltips upon mouseover, but for input fields only, hints show as an HTML placeholder within the field when the field is empty
Here is how hints appear depending on the type of control they are associated with:
LIMITATION: The minimal appearance is not supported on combined "Date and Time" fields and on text fields with "Character Counter" appearance.
NOTE: Only one minimal appearance can be used between oxf.xforms.label.appearance and oxf.xforms.hint.appearance. If both include minimal, the label wins.
For more about placeholders, see Use HTML5 placeholders, in XForms.
Display hints inline
[DEPRECATED SINCE Orbeon Forms 2016.2]
This property set whether the control hints are shown inline, rather than as tool-tips. The default is true.
<property
    as="xs:boolean"
    name="oxf.fr.detail.hints.inline.*.*"
    value="true"/>
Since Orbeon Forms 2016.2, this property is deprecated. Use oxf.fr.detail.hint.appearance instead. For backward compatibility, when this property is present, it overrides oxf.xforms.hint.appearance and sets it to:
full if set to true
tooltip if set to false
Order of LHHA elements
[SINCE Orbeon Forms 2016.2]
This property sets the respective order, in the generated HTML markup, of label/help/hint/alert and the control element.
NOTE: It is not recommended to change the default value of this property, which was introduced in the days where CSS couldn't do all it can do now. We recommend styling using CSS instead.
<property 
    as="xs:string" 
    name="oxf.fr.detail.lhha-order.*.*"                               
    value="help label control alert hint"/>
Initial keyboard focus
[SINCE Orbeon Forms 4.9]
This property controls whether Form Runner attempts to set focus on the first control upon form load. The default is true.
<property
    as="xs:boolean"
    name="oxf.fr.detail.initial-focus.*.*"
    value="true"/>
In some cases, such as embedding, it can be desirable to disable this by setting the property to false.
Focusable controls
[SINCE Orbeon Forms 2016.3]
The following properties determine which control types are focusable in in the following scenarios:
initial focus (if enabled by oxf.fr.detail.initial-focus)
switching sections in the table of contents
switching sections in the wizard table of contents or navigation
clearing the form data with the "Clear" button
moving, inserting, or deleting repetitions in repeated grids and sections
<property
    as="xs:string"
    name="oxf.fr.detail.focus.includes.*.*"
    value=""/>
    
<property
    as="xs:string"
    name="oxf.fr.detail.focus.excludes.*.*"
    value="xf:trigger"/>
Until Orbeon Forms 2016.2, only Text Fields (<xf:input>) were focusable in these cases. Since Orbeon Forms 2016.3, the default is to allow focus on any input control, including text fields, text areas, dropdown menus, and more. However, buttons are explicitly excluded.
The values of these properties follow the include and exclude attributes on the <xf:setfocus> action.
Validation mode
[SINCE Orbeon Forms 2016.3]
The following property controls whether validation happens as the user types or explicitly when activating a button:
<property
    as="xs:string"
    name="oxf.fr.detail.validation-mode.*.*"
    value="explicit"/>
Values:
incremental: validate as the user types (default)
explicit: validate upon explicit activation of a button
The main purpose of the explicit mode is to mimic old-style forms, where validation traditionally happened upon pressing a "Submit" button.
By default, in explicit mode, validation occurs:
when the validate Form Runner action runs
with the Wizard view, in validated mode, when the user attempts to navigate to the next page or select a page in the wizard's table of contents
Captcha
Enabling and choosing a component
If you are creating a public form, you might want to add a captcha to avoid spam. You can do so by enabling the captcha feature, which you do by adding the following property to your properties-local.xml:
[SINCE Orbeon Forms 2020.1]
<property
    as="xs:string"
    name="oxf.fr.detail.captcha.component.*.*"
    value="reCAPTCHA"/>
[UNTIL Orbeon Forms 2019.2]
<property
    as="xs:string"
    name="oxf.fr.detail.captcha.*.*"
    value="reCAPTCHA"/>
The property name changed in Orbeon Forms 2020.1 with the introduction of new captcha-related properties (more on this below). The old property name, without the component part, is still supported, but deprecated. You can set this property to either:
Blank (empty string), to not have captcha added to your form. This is the default.
reCAPTCHA or SimpleCaptcha, to use one the two captcha implementations built in Orbeon Forms. Also see which captcha is right for you.
[SINCE Orbeon Forms 2017.2] The qualified name of an XBL component you created and that implements a captcha, say acme:custom-captcha. When doing so, you need to have a namespace defined in your property file for the component prefix you're using, say xmlns:acme="http://acme.org/".
If using the reCAPTCHA, you'll also need to add properties to specify your reCAPTCHA public and private keys. For more on this, see how to set up the reCAPTCHA component.
Showing inside the wizard
[SINCE Orbeon Forms 2020.1] The following property allows you to configure where the captcha is shown (when enabled). The two possible values are:
form-bottom (the default value), to show the captcha at the bottom of the form.
inside-wizard to show the captcha inside the wizard. Only use this if your form is using the wizard view, otherwise the captcha won't show.
<property 
    as="xs:string"  
    name="oxf.fr.detail.captcha.location.*.*"                         
    value="inside-wizard"/>
Limitations
When all the following conditions are met:
The captcha is shown inside the wizard.
You have set the oxf.fr.detail.captcha.visible.*.* property (see below) to have the captcha show only on certain pages.
Users attempt to save or submit the form, or otherwise perform an action that requires data to be valid.
The captcha hasn't been solved yet.
Then:
While an error will show in the error summary to inform users that the captcha needs to be solved, when users click on the error message, Form Runner will not switch to the page where the captcha appears. (The situation here is somewhat different relative to what happens with normal fields, as depending on how you set the oxf.fr.detail.captcha.visible.*.* property, the captcha could appear on multiple pages.)
The page or pages in which the captcha appear won't be highlighted, as is the case for other invalid fields.
Captcha visibility
[SINCE Orbeon Forms 2020.1] When the captcha is enabled, you can control its visibility with the following property. The default value is true (shown below), and you can use a value template, to make it dynamic. For instance, you can have the captcha only show on the last page of the wizard by setting the above location property to inside-wizard, and this visible property to {fr:is-wizard-last-page()}.
Even when not visible according this property (i.e. your value template returns false), as long as the captcha is enabled, solving it is required; so this property isn't intended to be used to dynamically decide whether to have a captcha on a page or not, but it is to decide at what point during the form filling process you want the captcha to show.
<property 
    as="xs:string"  
    name="oxf.fr.detail.captcha.visible.*.*"                          
    value="true"/>
Running processes upon page load
[SINCE Orbeon Forms 2017.2]
Running processes in the background is an Orbeon Forms PE feature.
The following property controls what process(es) to run when the page loads in "new" or "edit" mode:
oxf.fr.detail.process.
  after-controls|after-data|before-data.
  background|foreground.
  new|edit|view|pdf|email.
  $app.
  $form
where $app and $form represent a Form Runner application name and/or form name or * wildcards, as is usual with Form Runner configuration properties.
The following process names apply:
after-controls: run after the controls are ready:
The process runs when controls are "live", which means you can set their values and list of choices.
after-data: run when the data is ready:
It has been loaded from the database if needed ("edit" mode).
Its initial values and calculations are up to date.
before-data: run before the data's initial values are calculated:
The process runs before the data is ready.
You cannot set control values and list of choices as a result.
WARNING: When running the process upon after-data, controls are not yet initialized. Because data validation depends on controls being present, data validation does not function in this case. If you need to validate data, for example before saving it or sending it, you must use the after-controls process name.
Background options:
background: run only in the background, that is within a service such as the "run form in the background" service
foreground: run only in the foreground, that is when the user is interacting with the page
*: run in both cases
Mode options:
new: run in "new" mode only
edit: run in "edit" mode only
etc.
*: run in all modes
NOTE: When running in the background, only the new and edit modes are supported.
See also Run form in the background.
Warning the user when data is unsafe
[SINCE Orbeon Forms 2018.2]
When data is unsafe, meaning that is has been modified but not saved yet, Form Runner by default shows a warning when attempting to navigate away from the current page or to close the current browser tab or window.
​
​
In some cases, in particular when embedding a form, this can be an inconvenience. The following property allows disabling this behavior.
[SINCE Orbeon Forms 2021.1] In addition to true or false, since the value of the property is an AVT, you can also, when needed, dynamically disable the warning by providing an expression between curly braces. For instance the following would only warn users if the content of the field named description has more than 50 characters and if users have made changes to the form since it was loaded:
<property 
    as="xs:string" 
    name="oxf.fr.detail.warn-when-data-unsafe.*.*"
    value="{string-length(fr:control-string-value('description')) > 50}"/>
[UNTIL Orbeon Forms 2020.1] The type of the property must be xs:boolean, and, consequently, the value must be either true or false.
<property 
    as="xs:boolean" 
    name="oxf.fr.detail.warn-when-data-unsafe.*.*"
    value="false"/>
See also the set-data-status action.
Initial data
When creating a new form (for instance going to the URL http://localhost:8080/orbeon/fr/orbeon/bookshelf/new), the initial form data (also known as "form instance" or "form instance data") can come from 3 different places:
1.The initial instance provided in the form can be used.
2.The Base64-encoded XML documented POSTed to the "new form" URI can be used.
3.A service can be called to get the initial instance.
Initial data posted to the New Form page
The instance provided in the form is used by default and the POSTed XML document is used if there actually is an XML document being POSTed.
The document can be POSTed in two ways:
1.As a direct POST of the XML document
2.As an HTML form POST parameter called fr-form-data
For #2, this behaves as if a browser was submitting an HTML form that looks like the following, with the value of the fr-form-data request parameter being the Base64-encoded XML document.:
<form method="post" action="/path/to/new">
    <input type="hidden" name="fr-form-data" value="Base64-encoded XML"/>
</form>
[SINCE Orbeon Forms 4.8]
The format of the instance data follows the Orbeon Forms 4.0.0 format by default. You can change this behavior to POST data in the latest internal format by specifying the data-format-version=edge request parameter. This is useful if you obtained the data from, for example, a send() action using data-format-version = "edge".
Use the authorization mechanism for services (see Authorization of pages and services) to enable submitting initial instances to the new page:
Your external application must provide credentials (e.g. BASIC authorization, a secret token, etc.) when POSTing to Form Runner.
Your authorizer service must validate those credentials.
[SINCE Orbeon Forms 2017.1]
If data-format-version=edge is not specified, then the data POSTed is assumed to be in 4.0.0 format.
[SINCE Orbeon Forms 2022.1]
Whe POSTing data as described above, the data can now be incomplete. Say the 4.0.0 format of your form data is:
<form>
  <contact>
    <first-name/>
    <last-name/>
    <email/>
    <phone/>
  </contact>
  <message>
    <order-number/>
    <topic/>
    <comments/>
  </message>
</form>
Let's say that you just want to pass the <last-name> and <order-number> comments. You can now just POST:
<form>
  <contact>
    <last-name>Washington</last-name>
  </contact>
  <message>
    <order-number>3141592</order-number>
  </message>
</form>
All other elements are automatically added.
NOTE: If the POSTed data contains extra XML elements in no namespace that are not supported by the form, an error is returned. However, extra XML elements in a custom namespace are allowed.
Compatibility: If the data posted contains extra elements in no namespace, those elements were ignored prior to Orbeon Forms 2022.1. With Orbeon Forms 2022.1 and newer, their presence causes an error.
Initial data from service
With the following properties, you can configure Form Runner to call an HTTP service instead of using the default instance provided as part of the form:
<property
    as="xs:boolean"
    name="oxf.fr.detail.new.service.enable.*.*"
    value="false"/>
​
<property
    as="xs:string"
    name="oxf.fr.detail.new.service.uri.*.*"
    value="/fr/service/custom/my-app/new"/>
Set the first property above to true to enable this behavior and have the second property point to your service.
The service is called with a GET HTTP method.
The service must either:
return a successful HTTP response containing XML data in the 4.0.0 format for the given form
return an empty body, in which case no error is produced (see also issue #3935)
return an error HTTP response or malformed XML response, in which case an error is produced and the form doesn't initialize
The following property defines a space-separated list of request parameters to be passed to the service. Say the new page was invoke with request parameters foo=42 and bar=84, if you set the value of this property to foo bar, these two request parameters will be passed along as request parameters to the service. The request parameters can either get to the new page in a POST or GET request. The service is always called with a GET, consequently request parameters will be passed on the URI.
<property
    as="xs:string"
    name="oxf.fr.detail.new.service.passing-request-parameters.*.*"
    value="foo bar"/>
The oxf.fr.persistence.*.data-format-version property does not affect oxf.fr.detail.new.service.enable and the data returned by the service must still be in 4.0.0 format in all cases.
Enabling oxf.fr.detail.new.service.enable doesn't change the behavior with regard to POSTed instance: even if you are calling a service to get the initial instance, the POSTed instance will be used when a document is POSTed to the corresponding "new form" page.
View mode
Buttons on the view page
You configure which buttons are shown on the view page with the following property:
<property
    as="xs:string"
    name="oxf.fr.detail.buttons.view.*.*"
    value="back workflow-edit pdf"/>
You can use all the buttons available on the Detail Page. In addition, the following buttons apply:
workflow-edit
Label: "Edit"
Action: Navigate back to the Detail Page in "edit" mode.
Showing alerts in view and PDF modes
[SINCE Orbeon Forms 2019.1]
The following property allows you to show alerts in the view and pdf modes. By default, the value is false and the alerts do not show.
<property 
    as="xs:boolean" 
    name="oxf.fr.detail.static-readonly-alert.*.*"
    value="true"/>
NOTE: Alerts show under the fields as usual. Setting this property to true doesn't cause the Error Summary to show.
Showing hints in view and PDF modes
[SINCE Orbeon Forms 2017.1]
The following property allows you to show hints in the view and pdf modes. By default, the value is false and the hints do not show.
<property 
    as="xs:boolean" 
    name="oxf.fr.detail.static-readonly-hint.*.*"
    value="true"/>
Calculations in readonly modes
The following property allows disabling Calculated Value formulas in readonly modes (Review, PDF). By default, the value is false and the calculations take place.
<property 
    as="xs:boolean" 
    name="oxf.fr.detail.readonly.disable-calculate.*.*"
    value="true"/>
See also Form Settings.
Grid tab order
[SINCE Orbeon Forms 2023.1]
You can configure the tab order in grids with the following property:
<property 
    as="xs:string" 
    name="oxf.xforms.xbl.fr.grid.tab-order.*.*"
    value="columns"/>
Valid values are rows and columns.
See also Grid Tab Order in the Grid Settings dialog.
PDF mode
See PDF configuration properties.
Form Runner
Attachments
Last modified 13d ago