For years now, developers have used complicated scripting and other desperate measures to create "dynamic forms." For instance, one commercial product I worked on (see http://www.Cardiff.com/LiquidOffice) used HTML divs to represent individual "pages" of a multi-page form, with script to swap the current page. Using XForms, the same effect can be accomplished declaratively.
The switch element is a container for case elements, usually two or more. At any given time, the contents of exactly one of the cases will be rendered in the final document, and the rest of the cases will be suppressed. One use of this is to provide tabbed interfaces, as Figure 6.10, “Tabbed interface demonstrating the switch element” shows, rendered with the open source Chiba project, available at http://chiba.sourceforge.net.
One immediate use of this feature is to provide a text message that only appears to non-XForms compatible browsers, by including a message in a case that gets hidden before the form displays. If XForms processing doesn't happen, then the initial message remains.
<model> <toggle ev:event="xforms-ready" case="go"> ... </model> <switch> <case id="default_message">You are using a browser that doesn't support XForms</case> <case id="go">...</case> </switch>
More generally, switch is useful for simulating pages, showing and hiding portions of the form, and enhancing the usability of forms by suppressing parts that don't matter at a given moment.
Each case element has a selected attribute, defaulted if necessary, that is visible to the host document, including DOM and CSS interfaces. Additionally, xforms-select and xforms-deselect events are dispatched to the individual cases, allowing event handlers to respond in a centralized manner to changes.