Structured Web Technologies

Structured Web Technologies

Results for:

element.type-cat-component Collapse

Prev Topic Next

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.

Struts 1.x Collapse

dataTable

display:table

display:table

The display tag provides a grid implementation, with many options that are desirable for most implementation.

Analysis

As mentioned earlier, the first step is to analyze the component. In this example, the analysis is based on basic usage of display:tag. This tag, like most useful components, has many features that depending on which of them are enabled; the composition of the rendered component could vary drastically. Some of the features that are omitted are sub-list, sorting, export and pagination. Including these features simply implies further analysis, which we avoided to make the example simple.

Layout

The layout is based on simple HTML table with thead, tbody and tfooter sections; whereas the body provides the rows and columns for the list.

Elements

Each column features an element that could be construed as an outputText. Most of the specifications for an output text have placeholders within this component, like caption, format, etc.

As mentioned, the component provides for columns that behave like output text with associated label or caption. This is when the column attribute, the default media type, is set to blank. However, for maximum flexibility an alternate media type could be set, amounting to graphics, excel spreadsheet, PDF, etc. With this option, any type of document, that is supported, could be included in the columns of the component.

Of interest here, is the media type "html", which allows us to include any HTML segment in the column. This would allow flexibility in mock-up, page design, and ultimately using simple elements. We shall use this to implement the links that would select items from the list.

Pass Through and Styles

Although we know the layout and type of elements involved, we do not have their identifier or the explicit elements to set their properties. We thus have to depend on pass through attribute. There are wealth of pass through attributes for this component that allow us to set the styles for the column and its header. Most important is the class attribute, which could be assigned with related entries included in the style sheet.

Another short cut is to use the default classes defined for the component, and provide styles for those. The implication is that there would be no need to worry about setting classes attribute in the final component. The design work would proceed and the components would eventually use them transparently. It is this method that would be employed in this example.

SPECIFICATION

Based on the analysis in the previous section, we derive a mock-up page for the suppliers list shown below.

Source Content

The source content that generate the page shown in fig. xx, is now listed below. It should be noted that we only include the code that relates directly to the component in question.

<!-- aws:element type="display:table" -->
<table cellSpacing=1 cellPadding=0 border="0">
     <thead>
     <tr>
	   <th><label for="supplierId">Supplier ID</label></th>
	   <th><label for="companyName">Company Name</label></th>
	   <th><label for="contactName">Contact Name</label></th>
	   <th><label for="contactTitle">Contact Title</label></th>
	   <th><label for="address">Address</label></th>
	   <th><label for="city">City</label></th>
	   <th><label for="region">Region</label></th>>
	   <th><label for="postalCode">Postal Code</label></th>
	   <th><label for="country">Country</label></th>
     </tr>
     </thead>
     <tbody>
     <!-- segment id="suppliersList" -->
     <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>
	   <td>
	   <!-- element type="outputText" id="address" -->
		  49 Gilbert St.
	   <!-- /element -->
	   </td>
	    <td>
	   <!-- element type="outputText" id="city" -->
		  London
	   <!-- /element -->
	   </td>
	   <td>
	   <!-- element type="outputText" id="region" -->
	   <!-- /element -->
	   </td>
	   <td>
	   <!-- element type="outputText" id="postalCode" -->
		  EC1 4SD
	   <!-- /element -->
	   </td>
	   <td>
	   <!-- element type="outputText" id="country" -->
		  UK
	   <!-- /element -->
	   </td>
     </tr>
     <!-- /segment -->
     </tbody>
<table>
<!-- /aws:element -->

The implication of this is that we have a complex element, captured by the following annotation.

        <!-- aws:element type="display:table" -->

        	This would enclose the presentation mock up of the component

        <!-- /aws:element -->

Layout

Within the annotations body is the mock-up for the component. We replicated the layout that matches what the component would render.

Elements

In our analysis we had concluded that there are column elements that are equivalent to the output text element. This we specify as we would for the standard element.

	<th><label for="companyName">Company Name</label></th>
	<td>
	<!-- element type="outputText" id="companyName" -->
		Exotic Liquids
	<!-- /element -->
	</td>

We also recognize an HTML segment that contains the anchor and output text elements; these are represented below.

	<th><label for="supplierId">Supplier ID</label></th>
	<td>
	<!-- aws:segment id=="template" -->
	<a href="#">
		<!-- element type="outputText" id="supplierId" -->
			1
		<!-- /element -->
	</a>
	<!-- /aws:segment -->
	</td>

Pass through and Style

For this example, we avoided pass through attribute. This is because of the additional steps that would be required to translate the attributes of the elements used for mock representation to the attributes of the final component. Whenever situation calls for, this might be necessary, but should be avoided when possible, because of the inaccuracies that could ensue.

For the presentation, what we rely on is the style settings. We had selected some default style classes used by the component, and provided values for them during the design process. Some of these classes are shown in the listing below.

With the entries tr.odd and tr.even, we were able to generate the alternate row highlighting as shown in fig x. With the thead entry, the background and fonts used by the heading was also set.

tr.odd {
  background-color: #ffffff;
}
tr.even {
  background-color: #def;
}
thead tr {
  background-color: #3399ff
}
th.sorted {
    background-color: #f90;
}

There are many other predefined classifications that could be set that are needed for the limited functions that we are including in the design.

Descriptors

The descriptor entries are straight forward, once the constituent elements are recognized.

The only thing to recognize is the fact that components would have sub elements that could have sub elements, etc.

The descriptors involved are shown below.

In this case, we have an element with identifier "list" with binding to a collection supplierList. This is just another element on the page; there are also buttons and hidden field on the page.

This complex element on the list form would be associated with another detailed form that provides the specification for its constituent elements. This is shown in the figure below.

The data sources for the bindings would be represented in the behavior descriptor, as shown below.

IMPLEMENTATION

Once the specification is complete, the implementation could be conducted, as it would be for standard elements. That is, we shall replace the component annotation with the final implementation tag, and transfer the behavior attribute to it.

The final implementation is designated as shown below:

In the figure below, we show the mappings between the descriptor and the final implementation tag.

The final rendering of the component is now shown below.

It should be noticed that other options were enabled in the final implementation, shown in the figure above. These are the export and the pagination features. We included these features to show that additional options could be added subsequently; as such the page design could be achieved on incremental basis.

Conclusion

The issue involving complex element is very important to dynamic web development. The hope is for the proliferation of such elements, such that options for features that are common to applications, from security login, grids, tabs and tree view, just to name some examples, are available for plugging into applications with relatively few lines of code.

Whereas the complexity encapsulated in these elements might be daunting in terms of presentation mock up. We have demonstrated with this example, that with the right planning, the implementation could be reduced to procedures involving manageable steps.

Furthermore, expansive discussion is devoted to this subject, in the User Manual, as to the process of analysis of such components.