Projects‎ > ‎

XForms - Core XForms Engine Improvements Proposals

NOTE: This page describes an Orbeon Forms project, not a feature which is currently part of Orbeon Forms.

Rationale

This page lists core XForms engine improvements we would like to see happen.

Orbeon Forms is open source and your help is appreciated. Post to ops-users or tweet us at @orbeon if you hare interested!

XBL

Automatic detection of noscript-enabled controls

Currently, the xxforms:noscript-supported property must be set by hand.

Plan is to determine the value automatically based on:

  • built-in controls which don't support noscript
    • HTML textarea
    • tree
    • menu
  • xbl:binding/xxbl:noscript-support="true" (or maybe something in xbl:template production)

Performance

Shortening of XForms class names in generated HTML

Currently, classes start with "xforms-*".

Plan:
  • Make the client-side markup and DOM smaller.
  • change to "xf-*"
  • possibly: shorten suffixes as well, e.g.:
    • xforms-enabled -> xf-en
  • Q: how to manage the transition, given the existing CSS? use a property to switch?

Features

Support for click/focus/blur/focusin/focusout DOM events

Rationale:
  • DOM 3 might deprecate DOMActivate/DOMFocusIn/DOMFocusOut
  • Not sure as of February 2010 whether new versions of XForms will deprecate those events
  • But it might still be a good idea to support the closely matching click/focus/etc. DOM 3 events

Questions:
  • How can the engine avoid dispatching too many events?

Scoped models

XBL components support nested models and instances. The notion could (and should) be extended outside components, as really the same code should handle that:
Example:

<xforms:repeat nodeset="...">
  <xforms:model id="my-scoped-model">
    <xforms:instance>
      <foobar/>
    </xforms:instance>
   </xforms:model>
   <xforms:input model="my-scoped-model" ref="."/>
</xforms:repeat>

[TODO: more brainstorming on this]

Architecture

Slight modifications to Ajax protocol

Currently, for historical reasons:
  • most controls output <xxf:control>
  • in addition
    • <xxf:attribute>
    • <xxf:itemset>
    • <xxf:div>
    • <xxf:repeat-iteration>
    • <xxf:text>
Desired:
  • everything is included within <xxf:control> element
  • use attributes or nested elements as needed
  • e.g. for an attribute:
    • <xxf:control id="foo" for="bar">value</xxf:control>
    • possibly use nested <xxf:value> for control value, could be optional
Benefits:
  • more consistent protocol
  • simplifies hierarchy of XFormsControl.outputAjaxDiff()
  • code is easier to understand on server
This also requires corresponding changes to client.

Streamline use of XFAnnotatorCH, XFExtractorCH

Proposal:
  • SAXStore produced by XFACH should not contain models and actions, only HTML and XForms controls
  • For XBL
    • must do exactly the same thing as top-level => better code reuse
      • output of XFACH must be SAXStore, not DOM
    • ideally: SAX the XSLT/XBL transformation (even pipeline???)
  • can XFACH and XFECH be refactored to produce the two outputs at the same time? probably!

Representation of XForms models

Plan:
  • Like for controls, no longer use DOM [DONE]
  • Use sister class of XFormsControl [DONE]
  • Proper hierarchy, like for controls [DONE]
  • Better evaluation of variables
  • Makes it easier to place models within controls with flexibility
NOTE: As of 2010-03, Model class holds some information already.

[TODO: elaborate]

xf:dispatch/@delay: improve handling of delayed events queue

  • order by expiration time
  • check queue "once in a while" to see if delay has elapsed
  • implement XForms 1.1 strategy of avoiding duplicate events

P2: Allowing asynchronous updates to an XForms document

There is a limitation right now which is that no async changes to the page can happen: only one client (the web browser) can make updates, in sequence. If you come in with an older dynamic state id, things won't work. In other words:
  • There is one live document...
  • for which there is exactly one client able to interact with it, that is a single window in a web browser.
Changing this would allow:
  • Fully asynchronous uploads able to update an instance directly
  • Asynchronous submissions able to modify the document upon xforms-submit-done/xforms-submit-error
  • Java or service APIs to perform async updates on XForms pages 
Use cases:
NOTE: An async update wouldn't be visible immediately to other clients of the document. Clients need to regularly poll, e.g. with a dummy event, to get the updates, (unless you have some comet style of connection open).

Ideas:
  • Architecture changed so that one live document
  • Idea of a "page generation id" which identifies the life of a particular page
    • NOTE: XFormsStateManager has an incomplete notion of currentPageGenerationId (incomplete because not used in case static state is cached)
  • P1 QUESTION: do we still need, in addition to page generation id, a dynamic state id? Mabye not!
  • Over the life of the page, the page generation id is passed alongside static state id and dynamic state id
  • When request comes in
    • sync on page gen id
      • NOTE: This requires changes, as currently our syncing mechanism is not reliable (but then it is probably not used atm anyway)
    • find latest dynamic state id for gen id
    • if passed dynamic state id is latest, then client was up to date and proceeds
    • if not, then
      • perform incoming actions on latest document (matching latest dynamic state id)
      • response must compute updates between passed dynamic state id and new


Comments