Page layout

XForms beginners are often wondering why XForms doesn’t provide any mechanism for page layout. The reason is the already mentioned abstract nature of XForms ā€“ to be truly device-independent no assumptions about the device’s capabilities can be made. Not even if there is something like ‘layout’ (like in voice applications). Thus XForms leaves the responsibility for a nice and ergonomic user experience to the host language.

The vendors of XForms implementations have found different ways to deal with this but over the years common patterns have evolved. Most implementers use CSS to style their XHTML/XForms documents and have setup their own CSS system of classes that allow to influence the rendering of forms. The specification defines some styles and pseudo classes for XForms but these are defined in CSS 3 which is not widely supported in browsers yet. Thus the implementers had to invent their own custom CSS classes to bridge that gap. This limits the portability of XHTML/XForms documents between implementations with regard to the look and feel. Nevertheless compliant implementations should correctly interpret the purpose of a form even if it looks differently.

The following sections outline some common patterns for layout and styling The patterns do not have to be used mutual exclusive. Instead it will be common to use mixtures of them. They are described as separate patterns here to point out the differences and consequences of each approach.

Direct layout

This pattern applies whenever a Form is layouted by markup contained in the host document e.g. through placing XForms controls into HTML table tags. This way the layout is hard-coded in the host language. This allows to use all features of the host-language but limits the device-independence of the form because not every client will understand this specific language or is limited in its interpretation.

For highly customized and complex pages this approach leads to a stable and reliable layout that works in many different browsers. It might also be useful when the author has limited CSS knowledge or the page is embedded into other pages that use complex CSS themselves. In this case CSS matchers may interfere and break some of your styling rules.

The drawback of this pattern is that the page will become much harder to modify when layout requirements change or new controls have to be added.

CSS layout

CSS layout is signified by a XHTML document container that uses minimal markup to embed the XForms. Most notably there will be a header and body section and probably a couple of HTML div elements for establishing the rough logical structure of the page. For maximum flexibility and changeability it should be avoided to heavily mix XHTML and XForms markup. Instead sections of XHTML and XForms should alternate and deep nesting of markup should be avoided.

CSS layout is especially well suited to be mixed with automatic layout via the XForms appearance attribute which is described in greater detail in section 4.6.

This pattern is recommended for production environments where device-independence and production efficiency is required and many forms have to be maintained. It allows single-source authoring for multiple clients and separates content from layout.

Though leading to cleaner and simpler markup this approach may require a bit more of planning than direct layout but the payoff is a much increased flexibility when it comes to changes of the overall look and feel.

Dojo layout containers

Dojo comes with a set of layout containers that can significantly ease the task of building dynamic layouts that work across different screen resolutions and browsers. You just have to write some simple HTML divs and assign the wanted layout declaratively. The implementation will take care of the rest and make sure that the layout adapts as wanted when the browser window is resized.

Using these readymade containers frees you from developing your own hand-rolled CSS rules and tests those against all the target browsers you’d like to support.

As with CSS layout careful planning avoids running into trouble so you should start with a simple layout and work forward into the details. For documentation on the several types of available layout containers please refer to the Dojo documentation found at http://docs.dojocampus.org/dijit/index .

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


%d bloggers like this: