Wednesday, March 28, 2012

TinyMCE control now in Form Builder, with HTML cleanup

Back in February, we were telling you about the new TinyMCE component. Since then, we have made a couple of important improvements to this component:
  1. It is now used in Form Builder when you insert an HTML text control, instead of the YUI RTE. The screenshot below shows what the TinyMCE control looks like now in Form Builder. (Doesn't it look exactly like the actual TinyMCE control? It does, because it is the actual TinyMCE control running there in Form Builder.)



  2. The TinyMCE component now does automatic HTML cleanup. This avoid having a tag soup in your data, and, more importantly, improves security by preventing XSS attacks. As a bonus, the code doing the tag soup parsing is now available in a processor: the TagSoup processor.

Wednesday, March 21, 2012

Be focused!

Contrary to what the title might suggest, this isn't a post on personal productivity or self-realization! Instead, we will be talking about keyboard focus.

We recently made a number of improvements to focus handling in Orbeon Forms, on two fronts:
  1. The XForms engine is more aware of which control owns focus.
  2. Focus in/out events are now handling container controls.
Say you have a group containing two fields: name and email, followed by a save button:


This corresponds to the following simplified XForms:
<group id="name-and-email">
    <input id="name" ref="name"/>
    <input id="email" ref="email"/>
</group>
<trigger id="save"/>
Starting with initial focus on name, when you navigate from the name field to the email field to the save button, focus events used to be dispatched as follows:
  1. DOMFocusOut on name
  2. DOMFocusIn on email
  3. DOMFocusOut on email
  4. DOMFocusIn on save
With the recent changes, you are also informed of the fact that focus has left the group:
  1. DOMFocusOut on name
  2. DOMFocusIn on email
  3. DOMFocusOut on email
  4. DOMFocusOut on name-and-email
  5. DOMFocusIn on save
Of course this works for DOMFocusIn as well, nested groups, and in fact any grouping control, including repeats, switches, and XBL controls. Focus is not only updated upon the user navigating between controls, but also when the user interface updates following UI refreshes and actions such as setfocus, setindex, toggle, show/hide, and insert/delete.

This behavior also makes perfect sense for XBL controls which are composites of other XForms controls. Say you have a composite control for dates with multiple fields:


You use this control this way in Orben Forms:
<fr:fields-date ref="date"/>
From the component user's perspective, fr:fields-date gets focus in/out events as if the composite control was a a single control. This satisfies the requirements for abstraction that come with XBL components, and in effect works like event retargeting specified by XBL 2 and the HTML Shadow DOM.

To learn all the little details, see the documentation.

Monday, March 19, 2012

The autocomplete gets a new labelref attribute

The autocomplete is a quite powerful but also fairly involved component. We've looked at how form authors use the autocomplete in Orbeon Forms, and found that in most cases they use it as an alternative to a combo box or radio buttons, for cases where the number of items to choose from is too large to be displayed in its entirety. The autocomplete then acts as a search interface to locate one specific item amongst many. In some cases, the number of items is so large, that it not only doesn't make sense to display all the items to users: it also wouldn't be reasonable to load them all in Orbeon Forms, on the server-side. In those cases, as users type in the field, you want the form to make a request to a service to load the items relevant to what users typed so far. To make that use case easier, last year we introduced the resource mode.


But the resource mode had one flaw. To see exactly what it is, let's first backtrack a bit. Items have two components: the label, which is shown in the UI, say "California", and the value, which is stored as part of the form data when users make a selection, say "CA". This is consistent with how things are done in XForms for all XForms selection controls. The trouble is that when users load a form where a value has already been selected, say "CA", we didn't know what to show in the autocomplete. Of course, you say, show "California"! But how can the autocomplete know that the label for "CA" is "California"? In resource mode, form authors give the autocomplete a service allowing the component to find items based on labels; but here we want to do the opposite: find a label based on the value. We could have asked form authors to provide another service, returning the label for a value. But this would have put more burden on form authors and could have caused performance problems on forms with several autocompletes, causing many service calls. So instead, we added a new labelref attribute, simply pointing to a node in the instance that will be used to store the label, so the component can store both the value and label of the selected item.

And for those of you using Form Builder, all of this is entirely transparent. You can forget what you just read about labelref, as Form Builder will take care of adding that attribute as well as a corresponding node in the instance.

Monday, March 12, 2012

More concise XForms

Recently we made a proposal to the XForms working group to help reduce the size of XForms code.

The XForms syntax is XML-based. When designing an XML vocabulary, it's often hard to choose between using elements or attributes. XForms has historically leaned toward using more nested elements [1], which tend to add more markup (you need pointy brackets and closing tags), and more lines (as you tend to indent nested elements for readability).

For example, compare the following HTML:
<select>
    <option>French</option>
    <option>English</option>
</select>
with similar [2] XForms:
<select>
    <item>
        <label>French</label>
        <value>fr</value>
    </item>
    <item>
        <label>English</label>
        <value>en</value>
    </item>
</select>
You notice how <label> and <value> are defined as nested elements and influence a lot the size of the markup.

The programmer community lately seems to have spoken in favor of concision, witness languages like Ruby, CoffeeScript, and Scala, and we agree at Orbeon that concision is a great thing when it removes boilerplate and does not come at the cost of readability. So we propose to use more attributes nested text whenever possible. The XForms above becomes then:
<select>
    <item label="English">en</item>
    <item label="French">fr</tem>
</select>
That's just an illustration of the idea and the next step is to figure out the details, specifically which new attributes to support and where to allow nested text (like in the <item> value above). In addition, we propose to use attribute value templates (AVTs) to handle dynamic values and keep the concise syntax. For example, to retrieve the label from localized resources:
<input ref="name" label="{instance('resources')/name}"/>
The good news is that the working group has received the idea positively so far!

[1] One exception is the XForms for HTML Working Draft, which introduces a set of attributes for the purpose of integration with HTML.

[2] To be fair we are not exactly comparing apples and oranges here as HTML doesn't separate label and value for items. So XForms does a little more, but at the (unnecessary) cost of a lot of extra markup.