In addition to the form's basic information, we have added a Form Statistics section, which tells you how many items you have in your form:
- sections
- repeats
- grids
- section templates
- controls
- total
For the longest time, we’ve been helping people posting questions about Orbeon Forms on Twitter. For questions that fit in 140 characters, and can be answered by an equally short message, Twitter is a great medium. Both questions and answers have to be short; this creates an expectation of those being “quick questions”, that can also be answered quickly. This increases the chance that we’ll answer throughout the day, which means you’ll get an answer faster. So we would like to encourage you to ask us your questions on Twitter, when you think it is appropriate.
There are of course lots of questions, comments, discussions that just don’t fit well the Twitter format. As now mentioned on the community page, we suggest[1] you:
This is of course just a suggestion. At the end of the day, do what you think is the most appropriate, and feel free to use the technology you are the most comfortable with. ↩
The new Form Builder look |
The new Form Runner look |
Form Builder is all about enabling form authors to create forms with a web-based tool, without having to write code. But then, in what format are the forms you create with Form Builder saved? Is it similar to when editing a document in Word, where your document is saved in a mostly opaque “Word format”? It isn’t: you forms are saved in XForms[1].
Using a standard[2], human readable, easily transformable format has lots of benefits. And we want to enable those of you who wish to do so, to go one level deeper: to be able to view and edit the XForms, directly in Form Builder. And this is why, the Form Builder code editor in the upcoming Form Builder 4.0[3] has been improved to do syntax highlighting, help with code indentation, highlight syntax errors, and more. We do all of this by leveraging the excellent CodeMirror component.
Or, to be more precise, forms are saved as XML in XForms+HTML+Form Runner, where the latter is used for higher level constructs that have no equivalent in HTML or XForms, such as section or grid. ↩
Modulo the Form Runner tags, which are specific to Orbeon Forms. ↩
At the time of this writing, Orbeon Forms 4.0 hasn’t been released yet, but you can already experiment with Orbeon Forms 4.0, including the updated source code editor, by using a 4.0 milestone build. ↩
Photo by Sebastian Bergmann |
Compared to general purpose languages, XForms and tools like Form Builder provide higher level abstractions tailored for a specific job: creating forms.
When you can implement your validation logic in a declarative way, does it instead make sense to program it in JavaScript, adapt that JavaScript to run on all mainstream browsers, and then write it again in Java so validation can also run on the server? Most likely not.
So, can we all forget about JavaScript, and use XForms instead? Certainly not! Orbeon Forms is itself implemented using general purposes languages, and there are time when the abstractions provided by XForms or Form Builder are not the right tool for the job. In those cases, you’ll want to write client-side or server-side code, and for that reason we’re working hard not only on making Form Builder better, but also on making underlying technologies better. This includes moving to modern and powerful technologies like Scala, CoffeeScript, LESS, and Bootstrap, but also improving the way those technologies integrate with XForms.
As an exemple, we’ve recently extended the JavaScript API to allow properties, or set of key/value pairs, to be sent along events, when dispatching an event from JavaScript to XForms. This makes it easier for your JavaScript code to communicate with your XForms code, something you would typically do when implementing your own widgets or form components using XBL.