Tuesday, June 26, 2007

Of state handling, part I

Rotor

Last week we fixed a few bugs related to state handling. Cool, you may think, but what is this state handling thingy about?

The idea is in fact fairly simple: user interfaces (and this is not limited to XForms or even to the web) usually need to keep track of some information to work properly.

First, there is information which never changes during the lifetime of the page. With XForms, this includes UI controls definitions, but also definitions such as models, submissions, bindings, event handlers, and actions. This may be contained in a static document on disk, but it may also be produced dynamically, with XSLT, JSP, PHP, you name it. In Orbeon Forms, this is called the page's static state.

Second, there is also information which may change as the user interacts with the form. For example, an XForms page uses XML documents, known as XForms instances, which store data captured and presented by controls. Instances can be changed over time by XForms action, user input, or talking to external services. They also hold properties determining whether controls using that data are visible, required, read-only, or valid.

The XForms page may contain switches (think "tabs", although there are other uses) which show only one of several parts of the user interface at a time. It is important to rember which part of a switch is visible. The page may also contain repeated sections with an associated selection index, which must be tracked. In Orbeon Forms, all this makes the page's dynamic state.

Static and dynamic state information (as a whole called state information) needs to be stored somewhere. Finding how to represent state information, as well as possible "somewheres" to store it is what state handling refers to.

We hope it's a little clearer now! We'll look into more details in a further post.

No comments:

Post a Comment