XForms patterns – the submission chain

March 17, 2011 at 11:14 pm 2 comments

Motivation: execute a submission only if another submission succeeds.

One of the most powerful features of XForms is the submission module. It is not comparable to the simple submission of a HTML form. Instead it allows you to have multiple submissions with different protocols, event handling and error reporting. However some powerful solution patterns are not obvious especially for XForms beginners.

A XForms submission is triggered by executing a XForms ‘send’ action so first thing most people try when they come to needing more than submission is to write:

    <xf:send submission="submission1"/>
    <xf:send submission="submission2"/>

This is fine as long as each submission is completely independent from the other and you even don’t care about the order in which they return. But most often this is not the case and you want more control.

Assume you have a situation where one submission depends on the outcome of another submission. Very often you do not want to even try a submit if a certain condition hasn’t been met. By chaining submissions you can achieve this. Consider the following example – we have two submissions ‘register’ and ‘postComment’. We want that it’s only possible to post a comment to our application if the user has been registered before. By using the XForms submission events we can tie the execution of ‘postComment’ to the ‘xforms-submit-done’ event of the ‘register’ submission.

If the registration fails we can inform the user and cancel the posting. If everything goes well we fire the second submission. Again here we can inform the user if a problem occurs.

<xf:submission id="register"
         <xf:action ev:event="xforms-submit-done">
               <xf:send submission="postComment"/>
               <xf:message level="ephemeral">You have been registered successfully</xf:message>
         <xf:action ev:event="xforms-submit-error">
               <xf:message>Sorry - your registration failed. You won't be able to submit your comment</xf:message>
<xf:submission id="postComment"
    <xf:action ev:event="xforms-submit-done">
        <xf:message>Your comment has been posted - thank you</xf:message>
    <xf:action ev:event="xforms-submit-error">
        <xf:message>You have been registered but the posting of your message failed</xf:message>

Of course you can add as many submissions to the chain as you like.

With conditional execution of actions (XForms ‘if’ Attribute) and the ‘event()’ function you can further refine the functionality to give more detailed information about errors or even trigger arbitrary logic to handle the different outcomes. Especially when interacting with webservices (in the broad sense) chained submissions give you very good control to handle service outages and give optimal feedback to the user.


Entry filed under: Uncategorized. Tags: , , .

Getting started with betterFORM limeGreen XML Summer School is using betterFORM

2 Comments Add your own

  • 1. alaincouthures  |  March 18, 2011 at 10:29 am

    The @if and the @while attributes can surely be used to treat such situations.

    Nevertheless, I’m more and more convinced that XForms actions should be also accessible from a script language. XQuery Update Facility is now a W3C Recommendation and it is a very good candidate for that.

    I want to experiment this as soon as possible within XSLTForms. Will betterform implement this too?



  • 2. joernturner  |  March 24, 2011 at 11:08 am

    Though this is kind of off-topic here – no, i do not think we’ll consider XQuery Update in the near future at least not as something to be tightly integrated. While i agree that it might be useful to have a script language interface, i don’t think XForms should add another new standard to the mix. One problem of XForms is that is already requires knowledge of CSS, XML, XSD, XPath, XForms DOM + DOM Events XHTML (in most cases) etc. Adding further standards does not help to spread the technology.

    After 10 years in XForms i’m all against adding new technologies – instead the existing functionality should be refactored for ease-of-use. The biggest hurdle for XForms always was it’s steep learning curve. Even after all those years i often have to consult the spec to write an insert action. That’s something that IMO deserves much more attention than to add more and more features.

    Also there’s is kind of a big overlap between XQuery update and XForms. I’d prefer not to extend that even further but to refactor complex actions like ‘insert’ for easier usage.

    When talking about script language today Javascript is surely the first candidate coming to mind. And from our experience this is what you need in complex projects – you’d like to have some JS API to talk to a XForms processor to handle the non-standard situations that come up in every project.. There hardly a web app project not using JavaScript today so it’s well-known and (with the help of some framework) quick to program. So i’m clearly in favor of a JS API instead of XQuery Update. This only adds another level of complexity and does not help users to use XForms. in contrast – it would lead to another long period of non-interoperable implementations.

    Well, much more could be said but probably that’s something we can talk about at the XML days.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

Recent Posts

betterFORM tweets

%d bloggers like this: