Tuesday, October 30, 2012

How many controls?

Orbeon Forms 4.0 comes with a new Form Settings dialog (which you open from the top right of the builder), where you can change the form's application and form names, as well as update its title and description.

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
This allows you to gauge the complexity of your form at a quick glance. We hope you like it!

Orbeon Forms 4.0 M13

Today we released Orbeon Forms 4.0 M13 (Milestone 13). Like 4.0 M12 and the previous milestones this is not a final release.

The last milestone introduced two big changes. M13 instead doesn't add anything big but focuses on fixing a series of issues:
  • Form Builder
    • Form Builder removes fr:buttons (#423)
    • Section template crashes (#516)
    • fr:dialog-select causes builder to fail to load form (#487)
    • Size source code editor dialog dynamically (#511)
    • Nested section icons are incorrectly positioned (#499)
    • Regression: Validation properties don't have any effect anymore (#524)
  • Form Runner
    • PDF: error in flying saucer (#483)
    • Improve how help icons shows (#257)
    • Textareas are not tall enough (#508)
    • Fix appearance of scrollable checkboxes (#509)
    • fr:us-phone doesn't appear in review mode (#517)
    • Set height of test dialog based on the viewport height (#519)
    • Fix issues with overriding custom buttons
    • Focus again on form after clear
    • CSS improvements to summary and detail pages
    • Oracle persistence: use dense_rank in search, which makes query simpler
    • XForms engine
      • Server sends unneeded itemset updates (#503)
      • Infinite loop with toggle on xxforms-invalid (#513)
      • JS exception with slider (#500)
      • Markup for xxbl:globals within xxforms:dynamic is not handled (#518)
      • Toolbar still shows when TinyMCE in Form Builder form is readonly (#175)
      • Checkboxes and radio buttons place Bootstrap classes
      • Support setting height on dialogs
      • New xxforms:has-class() function
      • New xxforms:classes() function
    More information is available in the in-progress release notes for 4.0.

    You can download the builds using these links:
    Don't forget to grab a trial license for the PE version.

    Please send feedback:

    Friday, October 26, 2012

    We love your questions on Twitter

    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:

    1. 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.  ↩

    Tuesday, October 23, 2012

    Orbeon Forms 4.0 M12

    Today we released Orbeon Forms 4.0 M12 (Milestone 12). Like 4.0 M11 and the previous milestones this is not a final release.

    This milestone is a rather big one, as we have just merged in (more than 170 commits!) a couple of major changes we have been working on since June:
    • A new Form Builder and Form Runner look based on Bootstrap
    • A much improved repeat editor in Form Builder

    The new Form Builder look

    The new Form Runner look
    We addressed the following issues in this build:
    • Form Builder
      • Improved look and feel
      • New repeat editor
      • Improved section and grid editors
      • Improved label and hint editors
      • Simplify handling of sections with the regular `fr:section` component
      • Forms crash on load (#482)
    • Form Runner
      • You do not have the privileges with noscript error summary (#406)
      • fr:section component uses native XBL labels, hints, help
      • Simplified implementation for the form table of contents
      • Upon load, form automatically focuses on first field able to accept input
      • Improved look and feel
        • Use Bootstrap 2.1.1
        • Use navigation bar at the top
        • Don't use YUI layout and tables anymore
        • Build CSS with LESS
        • Highlight main buttons
        • Control labels and hints properly wrap when too long to fit on one line
      • XForms engine
        • xxforms:case() not re-evaluated after xforms:toggle (#457)
        • Error evaluating itemset when control label contains HTML (#479)
        • Foreign content in the model is not recursively ignored (#494)
        • `xml:lang()` used in variable in the view return an empty string (#495)
        • xxf:dynamic NPE with update of XBL with models (#360)
        • Selecting a date/time has no effect on iOS 6 (#510)
        • Server sends type updates for fields other than input (#504)
        • Add new xxforms:cases() function
      In the next milestones we will polish things, including addressing the following known regressions from M12:
      • The button for automatic PDF is temporarily disabled in this milestone  (#483)
      • There are issues with custom buttons override
      More information is available in the in-progress release notes for 4.0.

      You can download the builds using these links:
      Don't forget to grab a trial license for the PE version.

      Please send feedback:

      Friday, October 12, 2012

      Better In-Browser Code Editing in Form Builder

      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.

      CodeMirror screenshot
      CodeMirror screenshot

      1. 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.  ↩

      2. Modulo the Form Runner tags, which are specific to Orbeon Forms.  ↩

      3. 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.  ↩

      Thursday, October 4, 2012

      Code reviews

      Photo by Sebastian Bergmann
      We started implementing regular code reviews at Orbeon a while back, and to our great satisfaction the practice has stuck!

      How do we do code reviews, concretely? Some companies have very drastic processes in place. For example, they won't allow anything into their master branch without a code review. And there's nothing wrong with that.

      At Orbeon we have implemented something a little bit more lightweight. We do reviews on weekly basis. Each Friday afternoon we stand around each other's computer (yes, stand!), and we review every commit pushed to github since the previous review.

      The programmer who has written a given change is the driver and explains the rationale behind it, pointing to non-trivial aspects if any. This results in discussions and feedback such as:
      • Discussing whether there might have been another (maybe simpler) solution to a problem.
      • Improving naming (one of the hard things in computer science).
      • Requesting that non-obvious code be commented better.
      • Discussing and explaining programming patterns.
      • Catching obvious little errors.
      We take note of changes required and address them individually after the review is over.

      We don't review necessarily every single line of code. Some changes can be complex (hopefully for good reasons) and it would take too much effort to dig all the way down. But at least we get an idea of the intent of the code.

      In the end, what do we gain? A better understanding of our code base, especially parts we are less familiar with; action items to improve code we have just written; and finally, we learn and, I think, become better programmers. It's probably worth the 1 to 2 hours a week we spend doing reviews!

      Wednesday, October 3, 2012

      Orbeon Forms 4.0 M11

      Today we released Orbeon Forms 4.0 M11 (Milestone 11). Like 4.0 M10 and the previous milestones this is not a final release.

      We have addressed the following issues in this build:
      • Form Builder
        • Can't reset max repeat to None (#433)
        • Don't generate type="xs:string|xf:string" on binds (#445)
      • Form Runner
        • Oracle flat view incorrectly contains null values (#427)
        • Calling a service on load fails (#435)
        • Service to return the XML Schema for a given form (documentation)
        • Fix PDF templates output of textarea (c4ca6cdf9f)
        • XForms engine
          • Added radio buttons in repeats don't reflect changes to the instance with IE (#430)
          • Controls with missing required binding are not marked non-relevant (72e55177d7)
          • Refactor XForms events and support client-side event properties (158b1ca4c5)
          • Support for properties in `dispatchEvent` API (60165aa888)
          • XForms inspector shows its own model (#429)
          • Support XForms 2.0 xforms:property child element (9f6bf048a3)
        • Security and authentication
          • Authorization for pages and services (#75)
          • Not found page doesn't send 404 code (#334#441)
          • Don't run PFC handlers for services (#440)
          • Blank page after authentication (#338)
        • Other
          • PEVersion hides exceptions in some cases (#428)
          • Examples: search field at the top right of the page not showing up anymore (#446)
          • Update YUI Compressor to latest version
          • Processor override does not work (#447)
          • More client-side refactoring
        With M10, services (in particular Form Runner services) could no longer be accessed externally at all due to the new security. In this build we have implemented a delegation strategy for the authorization of PFC pages and services. The approach is documented here. Feedback on this approach is greatly appreciated!

        More information is available in the in-progress release notes for 4.0.

        You can download the builds using these links:
        Don't forget to grab a trial license for the PE version.

        Please send feedback preferably to the ops-users list or via twitter (if short!), or feel free to comment on this blog entry if appropriate.

        Monday, October 1, 2012

        Getting XForms and JavaScript to be even better friends

        Brothers 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.