Wednesday, December 7, 2011

The state of Orbeon Forms, Part 10.2


This is the second and last part of "The state of Orbeon Forms, Part 10", covering the changes that have taken place since the release of Orbeon Forms 3.9 (part 1 is available here). This time we focus on Form Builder and Form Runner improvements:
  1. Form Builder
    • Access control for deployed forms. When using Oracle and MySQL, Form Builder can now specify fine-grained role-based access control for deployed forms. This will have to be implemented for eXist as well.
    • Services and actions in section templates. Form Builder services and actions now work within section templates. This is a long-requested feature! See also the section templates documentation.
    • Conditional actions. The Form Builder Action Editor now supports Run always/Run on creation only. See also the Action Editor documentation.
    • Grids withs more than 4 columns. Form Builder grids by default have a maximum of 4 columns. You can now optionally allow Form Builder to support more columns with a new property.
    • "Save as". Form Builder now has a "Save As…" button to save a form definition as a new document.
  2. Form Runner
    • reCAPTCHA. reCAPTCHA is now integrated with Form Runner. See Stop spammers by adding a CAPTCHA to your forms.
    • Improved persistence configuration. The main goal is to allow multiple SQL databases, each using its own datasource. See the compatibility notes.
    • Excel import. Quickly import form data from an Excel spreadsheet. See Excel import in Form Runner.
    • Required fields have an asterisk. See Styling required fields with a star.
    • Improved Liferay support. Liferay support had been improved quite a bit for 3.9, and has improved even more since then. In particular, there is a new asynchronous portlet content loading mode which provides better performance with slower browser, and many bug fixes to both the full portlet and the Form Runner proxy portlet.
    • XBL sections and grids. Form Runner sections and grids used to be implemented in XSLT, back when XBL support was not available. They have now been rewritten using XBL. See section.xbl and grid.xbl.
    • Font embedding in PDF files. See the documentation.
    • Third-party Alfresco persistence layer. See this blog post by Alexey, this presentation, and the source on github.
    • MongoDB persistence layer. This is still experimental. We got a nice contribution to support form definitions and attachments. See the source.
  3. Form Builder "next"
    • Dynamic XForms architecture. The next version of Form Builder uses a different approach at edit time. See Dynamic XForms and a new grid editor for Form Builder "next". This is cool because it is a solid foundation for nested sections, repeats, tabs, and live XBL controls in the builder.
    • New cell editor. A good part of the cell editor (in charge of editing a control's label and hint in particular) is now written in CoffeeScript on the client, the idea being to make it more responsive.
    • Nested sections. Some support for nested sections is now in. See also Dealing with nested sections in Form Builder.
    • Repeats. Support for repeats is partially implemented. Some rough edges still have to be handled.
As usual this does not include bug-fixes and other smaller improvements which you can follow on github.

Right now we are working hard on a couple of things, in particular:
  • Event handling refactoring. There are some unfortunate bugs related to event handling, especially in relation with XBL, which are hard to fix at the moment. Now that Form Runner sections and grids are implemented in XBL, it has become important to fix those issues. So we are refactoring the code in charge of events to make things easier to maintain.
  • Form Builder "next". This is the big piece! We are learning from our experience with Form Builder over the last few years and building on that for the next major release of Orbeon Forms. Things are starting to fall into place.
Enjoy,

-The Orbeon Team

The state of Orbeon Forms, Part 10.1

NOTE: Orbeon Forms 3.9 CE and PE were released in May 2011. This is a major release with lots of improvements. You might want to check what's new in that version first.

A lot has been going on since the last "The state of Orbeon Forms" post! This means that this new installment, covering improvements since Orbeon Forms 3.9, is in two parts. Here we focus on everything besides Form Builder and Form Runner:

  1. Security, performance and reliability
    • External XML DTDs. For security reasons, processing and loading of external DTDs when XML validation is turned off (which is in most cases) is disabled by default.
    • Better XForms error handling. Some runtime errors are now handled better and allow the XForms engine to continue processing. See also More resilient error handling in XForms.
    • Aggressive caching for all versioned resources. Until now, only JavaScript and CSS resources that were aggregated by the XForms server had aggressive caching settings. Now this is the case for any resources (typically JavaScript, CSS, images) that is versioned. This can lead to better performance if no further caching is implemented downstream (like by an Apache front-end).
  2. XForms engine and components
    • Native iPhone/iPad date and time widgets. This is pretty cool. See the blog post.
    • Input "placeholder". This causes either the label or the hint to appear on the background of the field when it is empty. The native HTML 5 implementation is used when possible. See the documentation.
    • New default button style. You know how buttons look different in every browser? We had a solution for this using the fr:button component based on YUI. Unfortunately this component uses JavaScript which causes some performance issues with older versions of IE. So we have now created a new CSS style for standard buttons which does not require Javascript. This is the default now for every standard button created with xforms:trigger. See also the documentation.
    • Improved autocomplete. The autocomplete control is now simpler for end-users  and easier for form authors. See Improved Autocomplete.
    • Improved xxf:valid() XPath function. This function has been updated to handle relevant nodes in the same way that xf:submission does. See the documentation.
    • New xxf:custom-mip() function. This function allows you to retrieve the value of a custom Model Item Property (MIP). See the documentation.
  3. XPL pipeline engine
    • Multiple XSLT outputs. You can now use xsl:result-document and the output: scheme in an XSLT transform placed in a pipeline. This allows an XSLT transform to produce multiple resulting documents for further processing in the pipeline.
  4. Architecture
    • Scala and CoffeeScript. Most of the new server-side code is now written in Scala (using 2.9.1) and most of the new client-side code is written in CoffeeScript.
    • Refactoring. Major refactoring of the XForms engine so-called static state has taken place to support dynamic XForms, a feature required for Form Builder "next". And more refactoring is on its way!
  5. On the side
    • XForms editorial meetings. Sub-groups in the XForms Working Group have met a few time to progress on XForms 2.0. In particular, we had a three-day meeting in Palo Alto, where good progress was made towards the XForms 2.0 spec.
This is for the important stuff, not counting numerous bug-fixes and other smaller improvements. If you are interested in the details, please follow the commits on github.

Part 2 will focus on Form Builder and Form Runner.

Enjoy,

-The Orbeon Team

Tuesday, December 6, 2011

Stop spammers by adding a CAPTCHA to your forms

If you're creating a form only accessible by members of your organization, chances are you're not worried about spammers. On the other hand, if your form is publicly available, and can be accessed anonymously, your form can easily become the target of spammers, hoping someone will read the content they submitted, or that this content will be published online, giving more weight to their site, through spamdexing.

Luckily, you can easily prevent spammers from exploiting your forms by adding a CAPTCHA. If you're writing your forms "by hand", in XForms, you can use the reCAPTCHA component. The component used the free reCAPTCHA service, provided by Google, and will show a challenge to your users filling the form, such as:


If you're creating your form with Form Builder, just enable CAPTCHAs for your form by setting the captcha-related properties, and Form Runner will take care of the rest for you, making sure that users entered a correct response before they can save or submit data.