The form descriptor captures the data interchanges that are typical of HTML forms, also captures validations and sequencing rules.

HTML FORM

It captures the logical representation of data forms, which could translate to the HTML form element. There could be multiple forms on the page. Some could be dynamically populated with data, but not posting data to the application. For example, the post could be to associates. There could also be static forms, like contact us form, that are not initially dynamically populated, but posted to application events.

For character stream based platform the implementations of the dWebSpec forms would correlate closely to the HTML element forms.

For component based platform,s the correlations are more logical that physical, to the HTML form element. This is because, component based pages, have the body of the page enclosed in a HTML form element tag, with a hidden field to maintain the page state. All elements on the page would then be part of component tree, which allows flexible binding options than could be afforded by the form and input element scheme used by HTML form.

The static or dynamic nature for the forms is less flexible for component based; all elements are part of the component tree. To explicitly exclude a portion of the page, special tags "verbatim", "literary" must surround those portions of the page.

dWebSpec is suited for capture of specification, whether component or character stream is in use. The value binding would represent the data mappings. For the component based, the component id would represent the identity on the server side for such components.

COMPONENT

Firstly, this discussion does not relate to the component or non-component architecture. In this case, the term component is used broadly like the word widgets. This could represent components on some platform, WebForm controls or tags in a tag library on others.

Components are also referred to as complex elements in dWebSpec terms. This term is used since elements, for which a standard set is defined; correspond mostly to HTML elements; whereas the complex elements might correspond to multiple HTML elements. Also, in terms of value binding, the simple element would correspond to single attribute. Whereas the complex ones could correspond to single attribute, but its sub elements could have multiple bindings.

A common example of complex element is the data table components available on most platforms.

A component would start as a (complex) element entry within a form descriptor; it would then have a separate form descriptor for further specification of its sub elements.

AGGREGATOR

Apart from the HTML form and component, there is a third category of usage that a form descriptor could fall into. This is the aggregator type. This is different from the other two in that it does not characterize real elements, complex or simple. It is also not for used for data or component binding specifications. It is meant to aggregate elements together for common validations and behavior specifications. There could be elements that share common formatting, like currency, or common application of a disable behavior. The affected elements would be itemized within a form descriptor of the aggregator type. The aggregator form itself would be represented in the main form descriptor that contains the full complement of the elements in the enclosing form.

It is all these possibilities that the form descriptor provide specifications capture for.

Because JSF is based on component architecture, the common representation of the form descriptor is not directly applicable. That representation usually translates to forms that are bound to objects, with the enclosed form elements bound to object attributes. For JSF, there is no value binding for forms, and the components that represent its fields could be bound to any object.

Other form level specifications, like client or server side validations, are rarely applicable because component architecture leads to encapsulation. Such specifications are usually relevant on a component by component basis.

JSF form is a naming container for the elements within it. One can think of a naming container as a unique namespace, for which all the identifiers for the elements within it must be unique.

The representation of the form component in the source content would be as follows.

<form id="uid">

</form>

The JSF form is represented by the h:form tag, which would represent the code above as shown below.

<h:form id="uid">

</h:form>

The rendered code would appear something like below.

<form id="uid" method="post" action= "pages/formPage.jsp"
enctype= "application/x-www-form-urlencoded">
</form>

There would be additional hidden fields used to maintain the page state. The method is always post, and the current page would be the action target.

COMPONENT

The concept involving using the form descriptor to expand on the specification of the complex element is uniform across platforms. An element that features in the form element as a component type would have a corresponding form descriptor that captures its sub-elements specification.

On the element descriptor discussion, this is exemplified with the dataTable. .

AGGREGATOR

The usage of the form descriptor as aggregator has no specificity to platform. It is a means of gathering elements for common specifications.

More details are available in the attributes descriptions