XForms, XForms Architecture

The XForms Architecture

Unlike some technologies, e.g. AJAX, XForms is much more than a collection of languages and techniques. XForms has a fully developed architecture and a complete set of design patterns.

To start with let's look at the heart of XForms architecture: The Model-View-Controller design pattern.

Most people that have studied MVC architecture agree on two aspects: The Model and the View. The model is where you store your data or your business objects. The View is what the user sees. But many variations of MVC have very different implementations of a controller. In the early days of SmallTalk at Xerox PARC the controller was related to user events and how they are gathered and dispatched. Today our input controls have much of the heavy lifting of events "baked into" them, so the form designers don't have to worry too much about handling mouse events and redirecting them unless they want specific behaviors. Many forms can be created without any knowledge of how events work.

To understand how XForms work you must understand that XForms has two trees in the browser.

The model is a tree that is not presented to the user directly and holds one or more instances and optionally some binding rules and some named events.

The view is a tree of presentation elements that the user sees. To build an XForms application you simply wire the two trees together using binding statements. And there are several ways to do this.

Where this page came from

This page was imported from Wikibooks. From “XForms” on Wikibooks, by its contributors, under CC BY-SA 4.0. Changed here: set as a page; navigation and edit links left out; each image under its own licence, credited in its caption.

Nobody has written it yet — it is the source material at a new address, which is why search engines are asked to skip it and why no one earns from it. It is up for grabs: take it on, and it is yours to rewrite and to earn from.