Standard event support
- Events in XForms
- Orbeon Forms support
ev:prefix for event attributes
- Registering event handlers
- Non-relevant event handlers
- Using the ev:observer and ev:target attributes
- The ev:propagate attribute
- The ev:defaultAction attribute
- Top-level event handlers
- Event handlers on XBL bound nodes
- Event handlers within XBL bindings
- Delayed events
- The ev:handler attribute
- The ev:listener element
- Historical note: differences between specifications
Events in XForms
Orbeon Forms support
ev: prefix for event attributes
The usual XForms way of using XML events is by prefixing attributes with the
ev: prefix. This is in fact not absolutely mandated by XForms, and leads to heavier attribute syntax, so Orbeon Forms allows using the attributes without a namespace. The examples below usually use the
ev: prefix, but most of the Orbeon Forms code doesn't.
Example with prefix:
<xf:dispatch ev:observer="child-instance" ev:event="xforms-insert" targetid="main-model" name="update-after-insert"/>
Example without prefix:
<xf:dispatch observer="child-instance" event="xforms-insert" targetid="main-model" name="update-after-insert"/>
Registering event handlers
[TODO: basic placement and ev:event support]
Non-relevant event handlers
[SINCE Orbeon Forms 2018.1]
Orbeon Forms now considers that non-relevant event handlers, that is handlers which are within non-relevant content, do
not run. Previously, such handlers would run. For example the following
<xf:message> actions never run:
<xf:group ref="()"> <xf:message event="xforms-ready" observer="my-model">Hello!</xf:message> <xf:group>
<xf:input ...> ... <xf:message event="xforms-disabled">I just got disabled!</xf:message> </xf:input
<xxf:dialog> ... <xf:message event="xxforms-dialog-closed">I just got closed!</xf:message> </xxf:dialog>
On the other hand, the following actions run:
<xf:message event="xforms-disabled" observer="my-input">I just got disabled!</xf:message> <xf:input id="my-input" ...> ... </xf:input
<xf:message event="xxforms-dialog-closed" observer="my-dialog">I just got closed!</xf:message> <xxf:dialog id="my-dialog"> ... </xxf:dialog>
For backward compatibility, if you need a non-relevant event handler to run, you can use the
<xxf:dialog> ... <xf:message event="xxforms-dialog-closed" xxf:if-non-relevant="true">I just got closed!</xf:message> </xxf:dialog>
But please note that running event handlers in non-relevant contexts can be tricky. In particular, the XPath context might be empty, and XPath variables might be undefined.
Using the ev:observer and ev:target attributes
ev:observer attribute allows you to register event handlers by specifying an element identifier, instead of embedding the event handler within that element. This is particularly useful to register event handlers on elements, which do not allow you to directly embed XML event handlers.
<xf:model id="main-model"> <!-- Child instance --> <xf:instance id="child-instance" src="my-instance.xml"/> <!-- Register the event handler on the child instance --> <xf:dispatch ev:observer="child-instance" ev:event="xforms-insert" targetid="main-model" name="update-after-insert"/> </xf:model>
Note that you still need to use the
ev:event attribute to specify to what event the handler responds. The following example shows how you can define event handlers for XForms elements anywhere in an XForms document:
<xh:html> <xh:head> <xf:model id="my-model"> <!-- A small instance --> <xf:instance id="my-instance"> <instance>initial</instance> </xf:instance> <!-- Event handler located in the model but observing an element in the view --> <xf:action ev:observer="my-group" ev:target="my-input" ev:event="DOMFocusIn"> <xf:setvalue ref=".">new</xf:setvalue> </xf:action> </xf:model> </xh:head> <xh:body> <xf:group id="my-group"> <!-- A simple XForms input control --> <xf:input id="my-input" ref="."> <xf:label>My Data</xf:label> </xf:input> <!-- Event handler located in the view but observing an element in the model --> <xf:action ev:observer="my-model" ev:event="xforms-ready"> <xf:dispatch name="DOMFocusIn" targetid="my-input"/> </xf:action> </xf:group> </xh:body> </xh:html>
The above example also shows how you can constrain an event handler to respond to an event dispatched to a particular target element using the
ev:target attribute. Here, the event handler responds to
DOMFocusIn events, but only those dispatched to the
The ev:propagate attribute
The ev:defaultAction attribute
Top-level event handlers
You can place event handlers at the top-level under the
<xh:body> <xxf:variable name="answer" select="42"/> <xf:setvalue ev:event="my-event" ref="value" value="$answer"/> ... </xh:body>
Previously, you had to use a top-level
<xh:group> for this to work:
<xh:body> <xf:group> <xxf:variable name="answer" select="42"/> <xf:setvalue ev:event="my-event" ref="value" value="$answer"/> ... </xf:group> </xh:body>
You can also explicitly register top-level handlers using the
#document observer id:
<xf:setvalue ev:observer="#document" ev:event="my-event" ref="value" value="$answer"/>
NOTE: Events from top-level models do not bubble to handlers observing on
#document. Arguably, they should!
Event handlers on XBL bound nodes
When using an XBL component, you can register handlers in the same way you register handlers on built-in XForms controls.
In this case, the handler is placed directly under the bound node (
<fr:foo id="my-foo"> <xf:setvalue ev:event="my-event" ref="my-value">43</xf:setvalue> </fr:foo>
Event handlers with the
ev:observer attribute are also recognized as long as the handler is directly under the bound node:
<fr:foo id="my-foo"> <xf:setvalue ev:event="my-event" ev:observer="my-input" ref="my-value">43</xf:setvalue> </fr:foo> <xf:input id="my-input" ref="my-value"/>
NOTE: For event handlers nested further within the bound node, the behavior is up to the XBL component. Typically, components that are containing controls, such as
<xf:input>, manage event handlers as you expect!
Event handlers within XBL bindings
Event handlers on XBL bindings are very similar to regular XML Events handlers, except:
- they use the
containing element placed within thesection of an XBL binding
- attributes do not use the XML Events namespace (typically with the
- the XBL 2
default-actionattribute is not supported but instead the XML Events 1
defaultActionis supported (both support the value
<xbl:handlers> <xbl:handler event="xforms-focus" phase="target" defaultAction="cancel"> <xxf:script id="xf-sf">YAHOO.xbl.fr.Currency.instance(this).setfocus();</xxf:script> </xbl:handler> </xbl:handlers>
Support and limitations
Orbeon Forms partially supports the XForms 1.1
delay attribute on
<xf:dispatch>. The limitations are:
- Events are not combined as specified in XForms 1.1.
- Custom event context information is not supported and simply ignored (see #2579).
Until Orbeon Forms 4.10 included:
- A delay greater than zero always incurs a round-trip with the client. This may mean higher latency and resource usage than could be expected. You are advised to use delays in the order of seconds at least.
- A delay of
0causes the event to be dispatched synchronously righ away, as if the
delayattribute is not present.
- A non-integer value causes the action to fail with an error.
Since Orbeon Forms 2016.1:
- Delayed events are checked for expiration before sending responses to the client.
- A delay of
0can be used to dispatch an event asynchronously with a guarantee that there will be no roundtrip to the client. This conforms to XForms 1.1.
- A non-integer value causes the event to be dispatched synchronously right away. This conforms to XForms 1.1.
The boolean attribute
xxf:show-progress allows specifying whether the client must enable the loading indicator when sending back delay events from the client. The default is
true and the indicator is used.
<xf:dispatch name="my-event" targetid="my-model" delay="2000" xxf:show-progress="false"/>
[UP TO 4.10] The
xxf:progress-message attribute allows specifying a custom progress message when
true. By default, the standard progres message is used. [SINCE 2016.1] Orbeon Forms switched to using a slim loading bar instead of a loading indicator message, and as a result specifying a "progress message" does not make sense anymore. The
xxf:progress-message attribute is deprecated: specifying it has no effect, and might be considered as an error in future versions.
For more information, see the XForms specification.
The ev:handler attribute
Not supported by Orbeon Forms.
The ev:listener element
Not supported by Orbeon Forms.
Historical note: differences between specifications
There are differences between some events specifications, in particular with regard to how events phases are defined hand how handlers can specify event phases.
- DOM Level 3 Events nicely clarifies the different event phases (capture, target, and bubbling).
- XML Events 1
phase="default"attribute means a listener is activated on the
- XML Events 1 does not support activating an event strictly on the
targetor bubbling phase.
- XBL 2 adds a default action phase separate from the
- XBL 2 proposes
default-action, and unspecified values for the phase attribute. If unspecified, this means the
- XML Events 2 is a W3C Working Group Note and covers declarative event handling for XML