On a few occasions in the previous chapters, we have already benefited from the event model. Events can be raised and listened to, just like in conventional programming languages. There are many standard events in the XForms standard, divided over four categories such as:
Many of these events are fired and handled during the interaction with the user – and we do not need to worry about doing anything with them – with the exception of the errors, which we should of course feed back to the user in an appropriate form.
We can also use events to make the form re-evaluate itself. As you will have understood by now, there can be many dependencies in XForms-specified forms. By just changing one input value it may be necessary to re-calculate other conditions. We have already seen the use of the DOMActivate notification in the previous chapter.
Our form has had the namespace xmlns:ev="http://www.w3.org/2001/xml-events" included from the beginning. The example in the previous chapter contained two “Add” and “Delete” buttons, or triggers in XForms terminology; both contained some logic that is executed under certain conditions and that raises a DOMActivate event on termination of the execution of that logic.
The XForms Engine should handle all standard XForms events; but we may want to use custom events for our own purpose as well. We will use custom events later to build a wizard surrounding our form.
For now, we will limit ourselves to showing an example of raising an event from our form using the dispatch function:
<xf:dispatch name="custom-myevent" targetid="model" />
Of course we have to specify the Model for which this event is being raised, which is why we pass the id of the model in the targetid attribute.
In the model, we then define an action that may contain some – or a lot of – manipulations of the data in the instance:
<!—do something here -->
This action will be executed every time the custom-myevent event is raised or dispatched.