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.

For ASP.NET, there could be only one of type 1) Form on a page. This would enclose all elements and segments on the page, representing the root of the component tree. Some of the form level attributes, like data source would be inapplicable. Whereas other form level attributes, like validations related ones, should be considered as page level specifications.

What could logically represent a 1) From type are components like formView and detailView. This is discussed further, in subsequent sections.

In the source content, all elements, segments, etc, (server controls) must appear within a <form> tag. The representation of the form component in the source content would be as follows.

<form id="order">

   . . . elements

</form>

The implementation translations involve inclusion in the <form> tag, the runat="server" attribute. The runat="server" attribute indicates that the form should be processed on the server. This also implies that the enclosed controls can be accessed by server scripts:

The implementation representation on the ASP.NET platform is as shown below.

<form id=="order" runat="server">

...HTML + server controls

</form>

<form name="order" method="post" action="order.aspx" id="order">

...some code

</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.