XForms:XForms In Applications
Propose
The target of the article is 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 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 demo to see the problems.
Now there are following mozilla based editors:
- Composer - (HTML editor) project is alive judge by glazman blog
- NVU - (HTML editor) it looks it freezed 2005 year
- Verbosio (XML editor) has't big progress now
- KomodoEditor - multi-language editor. The part of Open Komodo project which is going to be open source.
- ETNA - XML editor (see XML serializing bug 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 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 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 section on w3.org
- bug where the problem was discussed
- blocking 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 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 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 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 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.