Projects‎ > ‎XForms‎ > ‎

Uniform Document Object Model

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

Contents

  1. 1 Rationale
  2. 2 Ideas
  3. 3 Next tasks
  4. 4 Extractor/static state improvements
  5. 5 Towards new model scoping rules

Rationale

Currently, both statically and dynamically, controls, models, etc. are not represented as a uniform tree structure:
  • statically
    • PartAnalysisImpl holds model information separately
    • etc.
  • dynamically
    • XBLContainer/XFormsContainingDocument are special roots
    • models are contained within XBLContainer
This makes functions like id and XPath resolution harder than they need to be. The idea is to make everything uniform. This will make the architecture and algorithms easier to understand and less bug-prone.

Ideas

  • single tree with a single root
  • statically
    • single tree with a single root (RootControl extends ElementAnalysis)
    • use ElementAnalysis everywhere
  • dynamically
    • single tree with a single root
      • XFCD can can point to a root "control"
  • document root
    • first children are top-level models
    • following children are  top-level controls
    • implicitly, top-level controls get default model as first (in document order) sibling model
  • shadow tree root
    • follow similar structure as document root
    • always starts within shadow tree scope
    • all models are placed as children of shadow tree root, whether static or in template
  • event could flow from model to their root
    • models -> #document
    • XBL models -> XBL root
  • need a better term than "control" maybe

Next tasks

  • refactoring of static analysis
    • models as children of root
    • models as children of XBL root element
  • refactoring of dynamic tree

Extractor/static state improvements

[ADDED: 2011-11-30]

Currently:
  • extractor outputs SAX events used to create a dom4j document
  • that document is pulled apart in StaticStateDocument
  • further pulling apart takes place in PartAnalysisImpl.analyze.extractControlsModelsComponents
    • creation of controls document
    • extraction of nested models
This is wasteful. The analysis should just work on a single dom4j (ideally an immutable tree instead) produced only once. This is ins line with the uniform DOM idea above.

Steps to improve this:
  • extractor still writes dom4j (for now)
  • StaticStateDocument: remove creation of separate documents: keep the document intact!
  • PartAnalysisImpl.analyze.extractControlsModelsComponents: don't mutate document
  • if keeping pointers to elements is needed, just use references instead of extraction/copy
  • controls analysis
    • now: must skip nested model elements
    • later: control analysis just processes model like other controls -> need to handle 
  • check impact on serialization/deserialization and presence of XHTML subtree
Separately:
  • write the annotator/extractor as a single combined FSM

Towards new model scoping rules

Once this is implemented, implement XForms - Model Scoping Rules Proposal (to review first!). This would add:
  • arbitrary location of models
  • possibly: visibility of outer XPath context by models

Comments