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.

HTML FORM

Struts utilization of the Form descriptor is along the line provided by HTML form element. Every form descriptor would have a corresponding HTML form, at render time.

It is only the data displayed or submitted by the form that is represented on the server side; this is achieved on the Struts platform by employing the form-bean. The definition and life-cycle of the form bean is discussed under the subject of behavior-define.

In relation to the form-bean, the form and its constituent elements correspond to the form-bean and its attributes.

 For the implementation, this would show up as this on the page:

  <html:form action= "categoryData" >

  </html:form>
  

On the Struts platform, the transformation of the form in the source content to the implementation tag is somewhat convoluted. This is simply because the action is not registered against the form, but against the button or other elements that would trigger the post event. In terms of specifications, this is very logical, since it is possible for such event source to come from outside the form. Example is the master and detail forms, sometimes the master would trigger the post for the detail.

The starting point is thus the event source that would be associated with an action path. The form is the parameter for the request; all these data, along with the handler class would be registered in the configuration file.

  <action path="/categoryData"
  	type="com.struturewebtech.CategoryDataAction"
  	name="categoryForm" scope="request" 
  	input="/pages/ categoryData.jsp">

  </action>
  

It is this defined action path that would be used in the form implementation.

There are other aspects of the implementation, like validations, they are discussed with the descriptors attributes.

COMPONENT

The key to understanding the implementation of components has to do with the fact that they could be broken up into sub-elements. Those sub-elements would have specification relative to the component, as element of a form would.

As stated earlier, components are themselves elements, specifically complex element, which could be represented by form descriptors, in order to account for their sub-elements.

One of the standard elements is the dataTable, for which the DisplayTag component is commonly used on Struts platform. There is further discussion on this element, in the element descriptor section. This would illuminate the usage of form descriptors to capture component details.

AGGREGATOR

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