View source for XForms:XForms In Applications

== Propose ==

The target of the article is [http://www.mozilla.org/projects/xforms/ Mozilla XForms extension]. The article is designed to highlight existing problems of XForms usage in applications. We consider either XUL based or XHTML/AJAX applications. Mozilla XForms can be hosted in any of these documents.

The problems can fall into several categories:
* XForms in editor
* XForms and XSLT
* UI Binding in other XML vocabularies
* XForms DOM
* Dynamic XForms
* XForms controls
* Custom controls
* 1.1 specification support
* Regular XForms bugs

== XForms in editor ==

Mozilla XForms usage in editor isn't supported. The original problem is Mozilla editor doesn't work very well with XML elements. Moreover editor doesn't work fine with HTML Forms. It means caret navigation, selection are broken (for example, see a [https://bugzilla.mozilla.org/show_bug.cgi?id=293771 bug]). There is no working mouse interaction with form controls and it sounds like intentional behavior. But XForms in application requires to have analogue behavior with IE where every form control works as usually. You can play with [http://www.mozilla.org/editor/midasdemo/ demo] to see the problems.

Now there are following mozilla based editors:
* Composer - (HTML editor) project is alive judge by glazman blog
* [http://nvu.com NVU] - (HTML editor) it looks it freezed 2005 year
* [http://verbosio.mozdev.org Verbosio] (XML editor) has't big progress now
* [http://www.activestate.com/Products/komodo_edit/?CMP=ILC-koedi0207 KomodoEditor] - multi-language editor. The part of [http://www.activestate.com/openkomodo/ Open Komodo] project which is going to be open source.
* [http://rhaptos.org/downloads/editing/etna ETNA] - XML editor (see XML serializing bug [https://bugzilla.mozilla.org/show_bug.cgi?id=422403 bug]).

Currently these project don't suggest the way to get behavior we need.

Also it seems the required behavior doesn't contradict with mozilla editor. You can refer to the [https://bugzilla.mozilla.org/show_bug.cgi?id=369571 bug] targeted on this issue.

== XForms and XSLT ==

If applications pages are generated by XSLT then you should keep in mind XForms doesn't work after XSLT transformation (see a [https://bugzilla.mozilla.org/show_bug.cgi?id=294612 bug]).

== UI Binding in other XML vocabularies ==

XForms should be able to be extended by elements from other XML vocabularies. It means there should be a way to teach certain XML element to work with XForms model and instance data. You may find the following links useful.

* related [http://www.w3.org/TR/xforms11/#ui-binding-foreign section] on w3.org
* [https://bugzilla.mozilla.org/show_bug.cgi?id=306526 bug] where the problem was discussed
* blocking [https://bugzilla.mozilla.org/show_bug.cgi?id=358257 bug] (add XTF support for attributes)

== XForms DOM ==

Though XForms wasn't designed to be used with JS and XForms specification doesn't define a wide DOM but from time to time applications may require some access to XForms via JS. So
* if you need some more than rrrr on model then you should spend some time to develop XForms DOM (for example you can refer to the [https://bugzilla.mozilla.org/show_bug.cgi?id=333690 bug].
* you will get solution uncompatible with another XForms players

== Dynamic XForms ==

There is no guarantee XForms is up to dated when you modify document from script. For example, dynamicaly inserted XForms model isn't handled by XForms engine. Refer to the [https://bugzilla.mozilla.org/show_bug.cgi?id=323593 bug].

== XForms controls ==

XForms controls are implemented by XTF and XBL. Here there are few related problems:
* XForms controls use underlying native widgets from host document. Partitially it breaks styling of select/select1 controls. You can refer to the [https://bugzilla.mozilla.org/show_bug.cgi?id=344685 bug] to see list of problems.
* Be ready to get XBL related problems in complex applications

== Custom controls ==

Application may require new controls. You can create them via special Mozilla XForms interface and XBL. Also probably it makes sense to integrate controls from existing toolkit (like [http://dojotoolkit.org/ dojo] toolkit) with XForms.

== 1.1 specification ==

1.1 specification brings many useful things like extended behaviour of repeat module, new xslt functions and so on.

== Regular XForms bugs ==

There are still many important bugs we can't put into described above categories but they prevent regular work with XForms.