NOTE: This page describes an Orbeon Forms project, not a feature which is currently part of Orbeon Forms.
- define simple use case to use for full demo (spell checker?)
- implement most useful API to support use case
- DOM access
- local state
<xxf:script> action is extended to support a new
runat attribute which is set to value
<xxf:script runat="server" type="text/coffeescript">
In this case, the XForms engine must invoke the CoffeeScript compiler and pass the result to Rhino.
The script must have access to an API exposing useful aspects of the XForms runtime, including:
- access to XForms actions such as setfocus, etc.
- access to XForms functions such as index(), etc.
- read/write/mutate XForms instances, possibly through a DOM API
Use from XBL
<xbl:script src="/xbl/orbeon/foobar/foobar-server.js" runat="server"/>
Script imports API with require keywords:
var model = require('orbeon/xforms/model')
var myInstance = model.instance('my-instance')
var firstName = $('first-name', myInstance)
Script runs in scope that is automatically available from within XBL:
<xxf:script ev:event="DOMActivate" runat="server">
- how does script access correct local XBL model?
Use from the top-level
[TODO: top-level must also be able to include server scripts that expose functions]
- API to return instance (could be same as instance() / xxf:instance())
- returns a DOM which wraps around dom4j and is able to intercept mutation
- user will typically use jQuery or similar to navigate DOM of instance
- an XPath API could be provided as well and/or E4X support could be tried
- read control value
- write control value
Standard XForms actions:
- invalidateInstance / invalidateInstances
NOTE: the client-side API already features the following methods:
Standard XForms functions:
- readonly / relevant / required / valid / type
Standard functions that we probably don't need right away if at all:
- related to XPath limitations
Extension functions that we probably don't need right away if at all:
- encodeISO9075 / decodeISO9075
- attribute / element
Storing and retrieving state
Format should be limited to basic types and JSON (and possibly XML) so that state can be serialized and deserialized.
Script can store state information into models, including local XBL models. For example:
model.state.foo = < JSON or XML >
Q: Should there be a way of creating JSON XForms instances? This would allow the following scenario:
- JS/CS calls API to send submission
- submission returns JSON
- JS/CS consumes JSON
Issues with this:
- a JSON instance would be "foreign" in XML land
- no support for XPath bindings
- no access from XPath except through special accessor functions
Either way, the ability for JS/CS to leverage xf:submission to call services and get data back, typically in JSON format, should be supported.
XForms 1.2 might introduce Custom XPath Functions, which are meant to provide simple reusable XPath functions.
Options for defining functions (TBD):
- Functions might be defined in an
<xf:function> block. In this case, name and parameters are declared like for extension XPath functions using an XML syntax.
- Functions might be defined in an
<xxf:script> block. In this case, the script can simply expose functions as
Options for calling functions (TBD):
- If functions are defined in an
<xf:function> block, the will have a QName and can be called directly:
- All in-scope (and maybe exported) functions could be exposed through a standard namespace prefix, e.g.
- An XPath function could be used: