W3C XForms is a standard, markup-based, declarative, XML- and HTML-friendly user interface technology particularly adapted to building complex forms. XForms makes it easy to build dynamic user interfaces able to talk to XML services.
XForms 1.0 is a W3C Recommendation since October 2003, and XForms 1.1 is a recommendation since October 2009. The XForms Working Group is already embarking on XForms 2.0! Please visit the Forms Working Group for more information about XForms right from W3C.
XForms aims at improve upon HTML forms, but it is not strictly tied to HTML. The main goal of XForms is to make forms design easier, allowing the developer to write less client-side scripting (or none at all), and less server-side code thanks to a feature-rich declarative approach.
Benefits of XForms include:
See also the Orbeon Forms XForms Introduction section.
The Orbeon Forms implementation is based on the W3C XForms 1.1 Candidate Recommendation. The XForms engine in Orbeon Forms is close to supporting all of the XForms 1.1 specification. For more detailed information on what features are supported in the latest version of Orbeon Forms, see the XForms Compliance section of the documentation.
Orbeon Forms also supports a large number of extensions such as XPath 2.0 support, variables, XBL components, and much more.
See also our February 2012 blog post Does XForms need to be implemented natively in browsers?.
No, this is not a problem at all, because XForms runs great on the server, in the same way that other web applications technologies like PHP, ASP, JavaServer Faces or Ruby run on the server.
Running XForms on the server has even several benefits over running it in the client:
Historically, the XForms specification assumed that XForms was implemented on the client-side, natively within a web browser. But as discussed here, XForms-based applications can use server-side Ajax-based implementations that share XForms processing between server-side code and client-side code and rely on Ajax technology.
We believe that having an implementation of XForms with both a server-side and a client-side component, like Orbeon Forms, has a number of benefits, and in some situations, we think it is even essential.
The most important benefit is enhanced security. With Orbeon Forms, only the field values that need to be shown to users are sent to the browser, not your complete data model, as would be the case with a client-side implementation. If a field is readonly or has some other constraint placed on it, then that constraint is also checked on the server, not just on the client as would be the case with a client-side implementation. For selection fields, such as check boxes, radio buttons, and drop-downs, the server also checks that the selected value was indeed in the original list, and that it wasn't inserted in the list by a user trying to hack the system. If your form is calling REST or web services, those calls are made from the server. This prevents people from trying to hack the services by sending unexpected data, and your services can stay behind a firewall.
In some cases, Orbeon Forms, with its implementation split between the client and server, allows for better performance. For instance, this is the case when your form uses fairly large lookup tables, as any piece of data which supports the logic of your form but which isn't directly displayed to users doesn't need to be sent to the browser.
It is not a requirement to use XForms with Orbeon Forms. It is possible to generate HTML form elements and to examine request parameters manually. We recommend however using XForms whenever possible, because it provides an elegant abstraction that greatly simplifies form handling, which is the point of Orbeon Forms.
This happens because Orbeon Forms uses XPath 2.0 expressions instead of XPath 1.0 expressions as mandated by XForms 1.0 and XForms 1.1. This allows much greater flexibility in the expressions you can use in Orbeon Forms (and once you have tasted XPath 2.0, you can't go back to XPath 1.0!). For more information, see Note About XPath 2.0 Expressions.
Yes, you can use JSP alongside XForms, in the same web application or in a separate web application.
You can use JSP to produce pages containing XForms or other content to be processed by Orbeon Forms. See Using the Orbeon Forms XForms Engine with Java Applications.
If you feel more advanced, you can also "call" JSP pages with HTML links, or by redirecting or forwarding using the Redirect processor. You can also use the Servlet Include generator to include the content produced by a JSP.
It all depends on what you are trying to achieve with this integration. Technically, you can write a page in JSP + JSF that produces XForms, which can then be processed by the Orbeon Forms XForms engine using a Servlet filter approach. But mixing JSF components with XForms components can cause difficulties related to the way each component set handles form submissions and state. In particular:
Feel free to experiment with JSF and XForms together, but at the moment we recommend using either JSF or XForms exclusively in a given page. However you can very well use JSF for some pages, and XForms for other pages within the same application.
The great thing about Orbeon Forms and portlets is that there is very little difference if any between writing an application working in a portlet vs. a servlet. In fact, most of the Orbeon Forms XForms examples work unmodified as portlets. You can use some particularities of portlets, like preferences, and you have to be careful about paths to serve resources, but otherwise portlets are transparent to the developer. This contrasts with many other web platforms.
In other words, Orbeon Forms gives you the flexibility to write an application that works in standalone mode, and allows you to migrate to a portlet environment at minimal cost. This contrasts with many other web application technologies, which sometimes require you to rewrite your application entirely to fit within a portlet.
See the latest release notes for Orbeon Forms: Orbeon Forms 3.9.
Orbeon Form Builder is Orbeon Forms's visual form designer. You can also create forms by writing XHTML pages that contain embedded XForms markup.
Orbeon Forms comes with a tutorial which explains step by step how to create your first forms. We recommend you also look at the other sample Orbeon Forms applications that you find under your WAR file's
Also note that Orbeon provides services around Orbeon Forms, including training. Please visit our support page for more information.
Orbeon Form Builder.
If you just want to conditionally include XForms controls when the page is loaded, you can use an XSLT page view. If you want to control the showing or hiding of XForms controls after the page is loaded, you can use XForms relevance or switch/case. Currently, the only thing you can't do is dynamically add and remove trees of controls in a running XForms page.
In addition to the XForms engine, Orbeon Forms comes with an XML pipeline engine and a Page Flow Controller (PFC). While these additional building blocks are often useful to put together your form-based applications, you may not have a need for them.
The good news is that Orbeon Forms is very configurable and you are not forced to use XML pipelines or the PFC. Users have been successfully using the Orbeon Forms XForms engine with JSP/Struts or PHP. Please visit Using the Orbeon Forms XForms Engine with Java Applications for more details. Post additional questions to the ops-users mailing-list.
Remember that the Orbeon Forms XForms engine runs for the most part on the server. This means that when you perform an XForms submission that uses HTTP, that submission usually originates from the server, not from the client. Consider the following submission:
This is how this submission is processed.
This is why you see
Ideally, you would like to see
In short we don't believe we will solve this problem perfectly in the short-term, unless we get clever suggestions as to how this can be done.
Note that "nice" client-side URLs are already used in the following cases:
Finally, note that performing submission from the server offers certain advantages, including solving cross-domain access.
Web Forms 2.0 is a specification of WHATWG which describes a series of improvements over HTML forms. Since some key WHATWG members have joined the recently revamped HTML Working Group at W3C, there is a strong possibility that Web Forms 2.0 will be integrated (as is or with modifications) into the W3C's upcoming HTML 5 specification.
One of the main goals of Web Forms 2.0 is to be backward compatible with HTML forms. XForms on the other hand is a more radical departure from HTML forms due to its use of XML to store form data, a model-view architecture, and XML events and actions. Web Forms 2.0 does not support an XML data model, XPath, or XML schema validation. The closest Web Forms 2.0 comes to supporting XML is that it allows serializing form data into XML in a submission.
At Orbeon, we do not think that Web Forms 2.0 directly competes with XForms because it does not cover as much ground. We believe that for relatively large forms, an XML data model is absolutely necessary. We also believe that the declarative event and action model used by XForms is a huge benefit to form authors.
But Web Forms 2.0, or an evolution of it as part of HTML 5, could be leveraged by Orbeon Forms as it become supported by browsers.
We do not guarantee that Orbeon Forms supports DDA, but it seems that the first step of DDA is to comply with WCAG 1.0 priority 1 and 2 (or AA).
With Orbeon Forms, many points in WCAG 1.0 relate to HTML written by the page author. For those, Orbeon Forms is of course in theory compliant since this depends on how the page authors creates the HTML. Regarding the markup that Orbeon Forms generate automatically, in particular by Form Runner, we are doing everything we can to produce clean HTML, which helps a lot with making pages accessible. For example we generate HTML labels for all form controls.
Orbeon Forms 3.9 features a number of improvements for people using screen readers, like JAWS. We are committed to make Orbeon Forms accessible, so if you have any feedback on this topic, please contact us or post to the mailing-list.
As of Orbeon Forms 3.7, a component system for Orbeon Forms, based on XBL 2, is in place. For more information, see the developer documentation:
Note that Orbeon Forms already features some rich components such as menus, trees, dialogs, and autocompletion fields, and we plan to add more. All these features were sponsored by customers, so if you have particular needs you may want to consider sponsoring as that may be the quickest way to get your widget in the Orbeon Forms code base.
The short answer: yes. As of Orbeon Forms 3.7, the Orbeon Forms XForms engine has two modes:
For more technical information, visit the Noscript Mode developer documentation.
We don't believe it is realistic in the short term to migrate entire applications from Orbeon Forms to client-side implementations. There are multiple reasons for this: