component

Most of the standard elements, as defined within dWebSpec, have direct HTML equivalent elements. Because of such direct equivalence, the ability for mock representation could be assumed. This allows the premises of UI design and visual freeze, before the dynamic web design and integration.

There are however elements that do no map to single HTML element, example is the dataTable. These elements depend on the server-side amenities for their rendering. They would expose some settings and assume some default, or simple use layout that is not accessible for customization.

Because of the reliance on server side amenities, they are not easily open to mock up process, using static HTML. There are scheme for drag and drop design for these, within the platform specific IDE. Notwithstanding, this does not allow the choice of design environments, that are compatible with the other activities involved in User Interface engineering.

These elements are referred to as Complex Elements or Components. Their element type is categorized as "component", but the type would be the known name for the component on the platform. This could be dataGrid, calendarDate, etc., like components usually available on different platforms.

Because of the increasing importance of components on the various platforms, it would be necessary to include them in the specification scheme. In the discussion below, we explained how the mock-up and specification process is extended to components.

MOCK-UP

The first relieve comes from the fact that irrespective of the inner complexities of such components, they end up with rendering using HTML elements. The resultant HTML code is usually documented for the various options for the component. This would be the basis for the mock-up, which the UI design team would have as template for the component.

If for some reason, this documentation is unavailable, some sample implementation with typical component setting could be deployed. On displaying the examples in the browser, the save as option, could be used to capture the source code. This generated code would then be used as templates in the mock up process.

Most components use CSS styles, so that the aesthetic and theme could be set within the style sheet, without needing access to the component rendering code.

DESCRIPTORS
The component would be represent as an element. However, the single binding provided for an element would not suffice. For such, another form descriptor would be used to capture the sub-elements or the break down of the bindings.

In most cases, the sub-elements used for the mock-up process would reveal the break down of the binding. Notwithstanding, the binding required for the component would be published, what is needed is the extrapolation into elements that would use such bindings. One would keep in mind that this is for specification only.

Elements and Component

dWebSpec provides means of capturing the UI interface and dynamic specification of simple and complex elements.

For the simple element, the UI is represented by an HTML element, whereas the binding corresponds to single value, or collections.

For complex elements the UI could be represented by multiple elements, layout code and segments.

The implementation of complex elements involves prerequisites that are not associated with simple elements. This is involves the recognition of the layout and other nested descriptor specifications. The point is that, this does not involve the one to one equivalent between the source element and the final control.

Although there are effort that must be expended to establish the specification capture for complex element, based on the mode of usage of the component within the project or team. Once this becomes a template, it could easily be used in subsequent projects.

Two components shall be use to demonstrated the specification and implementation process, these are the FormView and GridView.

FormView

The starting point in the representation of the formView component is in the source content. The general layout of this component consists of segments. The core of this involves the templates that hold the presentation for view, edit, or insert modes.

This layout is as shown below.

Although they are shown in tab form above, they represent mutually exclusive segments.

This representation in the source content is shown in skeletal form below.

<html>
<head>
	<title>Category Data</title>
    <link rel="StyleSheet" href="main.css" TYPE="text/css"/>
</head>
<body>
<!-- aws:element type="messages" -->

<!-- /aws:element -->
<center>
 <br>
    <!-- aws:element type="FormView" -->
	<fieldset style="width:60%;">
    <!-- aws:segment id="InsertItemTemplate" -->
	<legend>Category Add </legend>
		<table>
		<tbody>
		<tr>
			<th class="rightLabel">Category Name<font color="red">*</font></th>
			<td align="left">
				<input type="text" name="categoryName" value="">
			</td>
			<td> </td>
		</tr>
		<tr>
			<th class="rightLabel">Description:</th>
			<td align="left">
				<input type="text" name="description" value="">
			</td>
			<td><!-- aws:element type="messages" id="categoryName" -->
					 <!-- /aws:element -->
			</td>
		</tr>
		</tbody>
		</table>
		<center>
				<input type="submit" name="buttonCancel" value="Cancel">
				<input type="submit" name="buttonSave" value="Save">
		</center>
    <!-- /aws:segment -->
    <!-- aws:segment id="EditItemTemplate" -->
	<legend>Category Edit</legend>
		<table>
		<tbody>
    	<tr>
			<th class="rightLabel" width="50%">Category ID:</th>
			<td width="50%">
				<!-- aws:element type="outputText" id="categoryId" -->
					3
				<!-- /aws:element -->
				<input type="hidden" name="categoryId" value="3">
			</td>
		</tr>
		<tr>
			<th class="rightLabel">Category Name<font color="red">*</font></th>
			<td align="left">
				<input type="text" name="categoryName" value="">
			</td>
			<td><!-- aws:element type="messages" id="categoryName" --> <!-- /aws:element --></td>
		</tr>
		<tr>
			<th class="rightLabel">Description:</th>
			<td align="left">
				<input type="text" name="description" value="">
			</td>
			<td> </td>
		</tr>
		</tbody>
		</table>
		<center>
			<input type="submit" name="buttonCancel" value="Cancel">
			<input type="submit" name="buttonSave" value="Save">
		</center>
    <!-- /aws:segment -->
    <!-- aws:segment id="ItemTemplate" -->
	<legend>Category View</legend>
		<table>
		<tbody>
    	<tr>
			<th class="rightLabel" width="50%">Category ID:</th>
			<td width="50%">
				<!-- aws:element type="outputText" id="categoryId" -->
					3
				<!-- /aws:element -->
				<input type="hidden" name="categoryId" value="3">
			</td>
		</tr>
		<tr>
			<th class="rightLabel">Category Name<font color="red">*</font></th>
			<td align="left">
				<!-- aws:element type="outputText" id="categoryName" -->
					Grains/Cereals
				<!-- /aws:element -->
			</td>
			<td> </td>
		</tr>
		<tr>
			<th class="rightLabel">Description:</th>
			<td align="left">
				<!-- aws:element type="outputText" id="description" -->
					Breads, crackers, pasta, and cereal
				<!-- /aws:element -->
			</td>
			<td> </td>
		</tr>
		</tbody>
		</table>
		<center>
			<input type="submit" name="buttonCancel" value="OK">
		</center>
    <!-- /aws:segment -->
	</fieldset>
    <!-- /aws:element -->
</center>
</body>
</html>

What to remember is that components could have special segments, with specific id, that would have specific ramifications. Examples of such are the segments with the following IDs: ItemTemplate, InsertItemTemplate and EditItemTemplate.

For the entry into the descriptor, it should be recalled that a component is an element that would have an entry in a form. An ASP.NET page would contain a form which encompasses all elements or components on the page; example of this is shown below.

This component is shown as a single element within the main form; of course there could be other elements or components in the form.

The component would now be associated with another form descriptor for the component that would show the list of elements within the FormView component. This is shown below.

The data source would be captured with the behavior-define descriptor as shown below.

This completes the capture of the specification for the sample FormView application.

The implementation would involve the combination of the source content with the entries the descriptor, using translation for the element type and other descriptor attributes. This would result in the following implementation for the page.

IMPLEMENTATION CODE

<fieldset style="width:60%;">
        <asp:FormView ID="CategoryForm" runat="server" DefaultMode="ReadOnly" DataKeyNames="Id" DataSourceID="CategoryData">
            <ItemTemplate>
	        <legend>Category View</legend>
	        <table>
	        <tbody>
            <tr>
		        <th class="rightLabel">Category ID</font></th>
		        <td align="left">
			        <asp:Label ID="LabelId" runat="server" Text='<%# Eval("Id") %>' />
		        </td>
		        <td> </td>
	        </tr>
            <tr>
		        <th class="rightLabel">Category Name</font></th>
		        <td align="left">
			        <asp:Label ID="Name" runat="server" Text='<%# Eval("Name") %>' />
		        </td>
		        <td> </td>
	        </tr>
            <tr>
		        <th class="rightLabel">Category Description</th>
		        <td align="left">
			        <asp:Label ID="Description" runat="server" Text='<%# Eval("Description") %>' />
		        </td>
		        <td> </td>
	        </tr>
            </tbody>
	        </table>
	        <center>
                <asp:Button ID="OKButton" runat="server" Text="OK" Width="6em" OnClick="OKButton_Click" />
	        </center>
            </ItemTemplate>
            <InsertItemTemplate>
	        <legend>Category Add</legend>
	        <table>
	        <tbody>
            <tr>
		        <th class="rightLabel">Category Name<font color="red">*</font></th>
		        <td align="left">
			        <asp:TextBox ID="Name" runat="server" Text='<%# Bind("Name") %>' />
		        </td>
		        <td> </td>
	        </tr>
            <tr>
		        <th class="rightLabel">Category Description</th>
		        <td align="left">
			        <asp:TextBox ID="Description" runat="server" Text='<%# Bind("Description") %>' />
		        </td>
		        <td> </td>
	        </tr>
            </tbody>
	        </table>
	        <center>
                <asp:Button ID="OKButton" runat="server" Text="OK" Width="6em" OnClick="OKButton_Click" />
                <asp:Button ID="CancelButton" runat="server" Text="Cancel" Width="6em" CausesValidation="False" OnClick="CancelButton_Click" /></td>
	        </center>
            </InsertItemTemplate>
            <EditItemTemplate>
	        <legend>Category Edit</legend>
	        <table>
	        <tbody>
            <tr>
		        <th class="rightLabel">Category ID</font></th>
		        <td align="left">
			        <asp:Label ID="LabelId" runat="server" Text='<%# Eval("Id") %>' />
		        </td>
		        <td> </td>
	        </tr>
            <tr>
		        <th class="rightLabel">Category Name<font color="red">*</font></th>
		        <td align="left">
			        <asp:TextBox ID="Name" runat="server" Text='<%# Bind("Name") %>' />
		        </td>
		        <td> </td>
	        </tr>
            <tr>
		        <th class="rightLabel">Category Description</th>
		        <td align="left">
			        <asp:TextBox ID="Description" runat="server" Text='<%# Bind("Description") %>' />
		        </td>
		        <td> </td>
	        </tr>
            </tbody>
	        </table>
	        <center>
                <asp:Button ID="OKButton" runat="server" Text="OK" Width="6em" OnClick="OKButton_Click" />
                <asp:Button ID="CancelButton" runat="server" Text="Cancel" Width="6em" CausesValidation="False" OnClick="CancelButton_Click" /></td>
	        </center>
            </EditItemTemplate>
        </asp:FormView>
</fieldset>

GridView

The starting point in the representation of the GridView component is in the source content. The general layout of this component consists of segments. The core of this involves the templates that hold the presentation for header, body (row-1, row-n), or footer sections.

This layout is as shown below.

Their representation in the source content is shown below.

<!-- aws:element type="GridView" id="List" -->
  <table cellSpacing=1 cellPadding=0 border="0">
  <thead>
  <tr>
  <th class="headers" ><label for="">Supplier ID</label></th>
  <th class="headers" ><label for="">Company Name</label></th>
  <th class="headers" ><label for="">Contact Name</label></th>
  <th class="headers" ><label for="">Contact Title</label></th>
  </tr>
  </thead>
  <tbody id="list.tbody">
  <!-- segment id="Columns" -->
  <tr class="even">
  <td>
  <!-- aws:segment id=="template" -->
  <a href="#">
  <!-- element type="outputText" id="supplierId" -->
  1
  <!-- /element -->
  </a>
  <!-- /aws:segment -->
  </td>
  <td>
  <!-- element type="outputText" id="companyName" -->
  Exotic Liquids
  <!-- /element -->
  </td>
  <td>
  <!-- element type="outputText" id="contactName" -->
  Charlotte Cooper
  <!-- /element -->
  </td>
  <td>
  <!-- element type="outputText" id="contactTitle" -->
  Purchasing Manager
  <!-- /element -->
  </td>
  </tr>
  <!-- /segment -->
  <!-- segment visible="false"-->
  <tr class="odd">

  Many rows could be included in the mock up
  Segment visibility set to false would remove them out the
  active markup

 </tr>
  <!-- /segment -->
  </tbody>
  </table>
  <!-- /aws:element -->
  

The columns above include simple elements of the outputText and link types.

There are some predefined elements called fields that could represent input/output column. These are command and template fields, discussed further below.

CommandField

This is used to specify dynamically generated links or buttons, for changing the row mode, and invoking update, select and delete. The mock representation of the field is exemplified below.

<td>
    <!-- element type="CommandField" -->
     <a href="#" id="Edit">Edit</a>
    <!-- /element -->
  </td>

Template Field

Another predefine field is the TemplateField. Like the FormView, the TemplateField has inbuilt segments, ItemTemplate and EditItemTemplate. Within these segments, multiple fields, custom controls and arbitrary HTML code could be included. Example is shown below.

<td>
    <!-- element type="TemplateField" -->
      <!-- segment type="ItemTemplate" -->
          <!-- element type="outputText" id="companyName" -->
         Exotic Liquids
          <!-- /element -->
      <!-- /segment -->
      <!-- segment type="EditTemplate" -->
              <select name="customerId"  id="customerId" size="1">
                   <!-- aws:element type="options" -->
                   <option value="ALFKI">Alfreds Futterkiste</option>
                   <option value="ANTON">Antonio Moreno Taquera</option>
                   <option value="BERGS">Berglunds snabbk&#246;p</option>
                   <option value="BLAUS">Blauer See Delikatessen</option>
                   <!-- /aws:element -->
              </select>
      <!-- /segment -->
    <!-- /element -->
  </td>

 

As would be seen in the transformation table, not every element type has an equivalent column field type. For the rest, the generic TemplateField would apply.

Whenever multiple controls are specified for a column, the template field must be used to include them. One thing of note of note is that the standard input fields for the Grid would automatically adapt to the modes whether read only or read write. For this field, separate display only or edit set of elements must be provided. The example above shows these set as separate segments.

GridView Representation in the Descriptor

A component starts off as an element in a form descriptor. An ASP.NET page would contain a top level form which encompasses all elements or components.

This component is shown as a singly element within the main form; of course there could be other elements or components in the form.

There would be another form descriptor for the component, that would capture the list of elements within the GridView component. This is shown below.

The behavior descriptor defines the collection bound to the column, as shown below.

This completes the specification for the sample GridView application.

NOTE: It is noteworthy that the selection of layout and segments used to represent the internals of the component could be selected to suit the specification capture. For example the columns are bound to the properties with an object in a collection (![].CategoryName). Alternatively, the row that contain the column definitions could be enclosed in a segment that that has behavior-repeat applied. The advantage of this is that the repeat behavior has parameters for specifying page size and starting points that could be used to capture the paging requirements. Consult the behavior-repeat descriptor for more on this.

The implementation would involve the combination of the source content with the entries in the descriptor, using translation for the element type and other descriptor attributes.

The translation table is shown below.

Example implementation code is shown below. This exemplifies the use of two of the standard column fields.

<asp:HyperLinkField runat="server" 
         HeaderText="Supplier ID" 
         DataTextField="SupplierID" 
         DataNavigateUrlFields="SupplierID"
         DataNavigateUrlFormatString=
           "http://yoursite.com/showsupplier.aspx?id={0}" />
  <asp:BoundField runat="server" 
         HeaderText="Company Name" 
         DataTextField="CompanyName" />
  <asp:BoundField runat="server" 
         HeaderText="Company Title" 
         DataTextField="ContactTitle" />
</asp:GridView>

In the transformation table, there are two special fields that do not directly translate into simple elements. These are CommandField and TemplateField, these are discussed below.

CommandField

The CommandField could be represented in the source content, to enclose a set of buttons or links. Irrespective of the buttons shown, the real assemblage of buttons that would show on runtime would be dependent on the mode. It is better to establish a global scheme or style for showing buttons within the grid, the representation in the source content would simply be translated to the target global implementation.

<td>
    <!-- element type="CommandField" -->
     <a href="#" id="Edit">Edit</a>
    <!-- /element -->
  </td>

The implementation of the enclosed buttons is through CommandField, which display command buttons that perform delete, edit, insert, or select operations. The command buttons to perform these operations can be shown or hidden using the following properties: ShowDeleteButton, ShowEditButton, and ShowSelectButton.

In the edit or insert mode, the Cancel button is displayed; in order to hide the button ShowCancelButton property could be employed.

The text shown on the buttons could be customized with these properties.

There is an option to set the type of button to display, by using the ButtonType property. The options are Button, Link, and Image.

For the image type, the image URL would be set with the following properties: CancelImageUrl, DeleteImageUrl, EditImageUrl, SelectImageUrl, and UpdateImageUrl.

Clicking a button in a CommandField field would byy default, cause validations to be performed on all controls on the page. This could be prevented by setting the CausesValidation property to false.

Sample implementation is shown below.

  <asp:CommandField ShowEditButton="True"></asp:CommandField>

Template Field

The fields shown in the translation table are very convenient. Example is BoundField that allows simple implementation of an element that could be eventually be an output or input text, depending on the mode the row is in. The attribute DataFomatString is provided that allows the specification of format for the input.

If the element involve has other specifications pertaining to validation, validation group, etc., the standard mappings shown in the overview section would be needed.

By perusing the transformation table, it could be perceived that not all elements are represented. Examples of element not represented are element of the selection category, like dropdown lists.

It is the TemplateField that provides the accommodation for these. Within a template field one or more element from the full repertoire of the element list could be include, without restriction on their specification. You would have to specify the elements and specification for the display, edit or any other mode that could be in use.

Template example is shown here.

  <td>
    <!-- element type="TemplateField" -->
      <!-- segment type="ItemTemplate" -->
          <!-- element type="outputText" id="companyName" -->
         Exotic Liquids
          <!-- /element -->
      <!-- /segment -->
      <!-- segment type="EditTemplate" -->
              <select name="customerId"  id="customerId" size="1">
                   <!-- aws:element type="options" -->
                   <option value="ALFKI">Alfreds Futterkiste</option>
                   <option value="ANTON">Antonio Moreno Taquera</option>
                   <option value="BERGS">Berglunds snabbk&#246;p</option>
                   <option value="BLAUS">Blauer See Delikatessen</option>
                   <!-- /aws:element -->
              </select>
      <!-- /segment -->
    <!-- /element -->
  </td>

  

This would be transformed into the following implementation code.

<asp:TemplateField HeaderText="Supplier"> 
      <ItemTemplate>
          <%#Eval("Suppler.CompanyName")%>
    </ItemTemplate>
      <EditTemplate>
              <asp:DropDownList ID="SupplierID" 
                      DataSourceID="SupplierDataSource"
                      DataValueField="SupplierID"
                      DataValueField="CompanyName"
                      DataValueField="<%#Bind('SupplierID')%>"
                      runat="server"/>
      </EditTemplate>
</asp:TemplateField>