Syntax

Search…
Syntax
Defining a process
A process is defined with some text following a specific syntax. For example:
1
require-uploads
2
then require-valid
3
then save
4
then success-message("save-success")
5
recover error-message("database-error")
Copied!
This follows a DSL (domain-specific language) described in more details below. The process DSL supports:
actions with or without parameters
combinators to handle success and failure
grouping with parentheses
conditions ("if")
sub-processes
a set of standard actions, including:
​core actions​
​Form Runner actions​
​XForms actions​
Exposing a process
You expose a process with a property (typically in properties-local.xml) starting with oxf.fr.detail.process. For example:
1
<property as="xs:string" name="oxf.fr.detail.process.save-final.*.*">
2
    require-uploads
3
    then require-valid
4
    then save
5
    then success-message("save-success")
6
    recover error-message("database-error")
7
</property>
Copied!
The name of the process immediately follows the property prefix, here save-final.
The wildcards, as usual with Form Runner, can specify a form's application and form names. Here, the process is available to all forms in all apps because of the *.* wildcard.
Simple actions
Actions without parameters
Some actions, such as the email action, don't have or don't require any parameters. You just write the name of the action:
1
<property as="xs:string" name="oxf.fr.detail.process.email-my-form.*.*">. 
2
    email
3
</property>
Copied!
Sending emails is configured with properties. To send a form my-app/my-form to an email address [email protected] using for instance the SMTP server smtp.example.org you can add the following properties to properties-local.xml:
1
<property as="xs:string"  
2
    name="oxf.fr.email.smtp.host.my-app.my-form"          
3
    value="smtp.example.org"/>
4
<property as="xs:string"  
5
    name="oxf.fr.email.from.my-app.my-form"               
6
    value="[email protected]"/>
7
<property as="xs:string"  
8
    name="oxf.fr.email.to.my-app.my-form"                 
9
    value="[email protected]"/>
10
<property as="xs:string"  
11
    name="oxf.fr.email.smtp.username.my-app.my-form"      
12
    value="[email protected]"/>
13
<property as="xs:string"  
14
    name="oxf.fr.email.smtp.credentials.my-app.my-form"   
15
    value="******"/> <!-- replace with the password to access the SMTP server-->
Copied!
Actions with parameters
[SINCE Orbeon Forms 4.4]
In Orbeon Forms 4.2 and 4.3, actions support only an anonymous default parameter. With 4.4, actions support named parameters in addition to an anonymous default parameter:
1
send(
2
    uri      = "http://acme.org/orbeon",
3
    annotate = "error warning",
4
    replace  = "all"
5
)
Copied!
Combining actions
Running a single action might be useful, but it is much more useful to combine actions. This means that you must be able to:
specify which actions to run and in which order
decide what to do when they succeed or fail
decide how to associate them with buttons
For this purpose, the following combinators are defined:
then: used to specify that the following sequence of actions must run if the current action succeeds.
recover: used to specify that the following individual action must run if the current action fails. Once the following action has run, processing continues successfully.
With actions and combinators, the syntax becomes:
The process must start with an action or a sub-process.
The process must also end with an action or a sub-process.
Two actions or sub-processes must be separated by a combinator.
Some actions have parameters
For example, the behavior of the "Save" button, associated with the save-final process, is specified this way:
1
require-uploads
2
then validate-all
3
then save
4
then success-message("save-success")
5
recover error-message("database-error")
Copied!
Notice that there are:
action names, like save and success-message
sub-processes, like require-uploads and validate-all, which run a number of steps and stop processing if uploads are pending or the data is not valid
the two combinators, then and recover
So in the example above what you want to say is the following:
start by checking that there are no pending uploads
if there are, the process is interrupted
then in case of success validate the data
if it's invalid, the process is interrupted
if there are warnings or info messages, a dialog is shown to the user
then in case of success save the data
then in case of success show a success message
if saving has failed, then show an error message
A process which just saves the data without checking validity and shows success and error messages looks like this:
1
save
2
then success-message("save-draft-success")
3
recover error-message("database-error")
Copied!
Validating and sending data to a service looks like this:
1
require-valid
2
then send("oxf.fr.detail.send.success")
Copied!
Some actions can take parameters. In the example above we point to properties to configure the send action. This means that, within a single process, you can have any number of send actions which send data to various services. This also allows you to have separate buttons to send data to different services. These two scenarios were not possible before.
Grouping actions
[SINCE Orbeon Forms 4.4]
You can use parentheses to group actions. For example:
1
visit-all
2
then captcha
3
then validate("error")
4
recover (
5
    visit-all
6
    then expand-all
7
    then error-message("form-validation-error")
8
    then success
9
)
Copied!
Here recover processes the entire content of the parentheses. Without the parentheses, only visit-all would be processed by recover, and the subsequent expand-all would run whether the preceding actions are successful or not.
Conditions
[SINCE Orbeon Forms 4.4]
You can use if to evaluate a condition during the execution of a process. The condition is expressed as an XPath expression and runs in the context of the root element of the main form instance:
1
if ("//secret = 42")
2
then success-message(message = "yea")
3
else error-message(message = "nay")
Copied!
The else branch is optional. This means that the following two lines are equivalent:
1
if ("xpath") then action1 then action2
2
if ("xpath") then action1 else nop then action2
Copied!
The if and else operators have a higher precedence than the then and recover combinators. This means that if you need more than one action to run in either one of the branches, parentheses must be added:
1
if ("xpath") then (action1 then action2) else action3
Copied!
This also means that the following two lines are equivalent:
1
if ("xpath") then action1 else action2 then action3
2
(if ("xpath") then action1 else action2) then action3
Copied!
Buttons and processes
Core actions
Last modified 1yr ago
Copy link
Contents
Defining a process
Exposing a process
Simple actions
Actions without parameters
Actions with parameters
Combining actions
Grouping actions
Conditions