message

The message category covers the messages element of dWebSpec.

This category captures the various way platforms would capture messages and display them on the page view.

The messages element provides messages for the page or enclosing form; whereas the message element provides messages for individual elements.

Some of the features provided by platforms are, Categorization of messages, Standardized error messages, Field error messages, and internationalization. These are expanded upon below.

Categorization of messages

This involves means of grouping the errors into categories, which would allow showing the appropriate messages, as relevant or per user customization. It also allow applying different styles to the messages, for instance red fonts for errors, and green for informational.

Standardized error messages

A scheme is usually provided to define a list of standardize messages. These messages would allow some level of customization, by including tokens or place holder that could be replaced with predetermined or ad-hoc strings.

There would also be standard means to add custom messages at runtime.

Field Errors

The standardized errors could be leverage to allow passing the field label as parameter to make it appear field specific.

The validator would allow for message specifications. The syntax is as follow; it should be noted that the variables required vary for the different validations.

Validator:message,variable1,variable2,...

Example being: MaxLengthValidator:"Text must be less than 24 characters",25

Specification of element validation messages in dWebSpec.

Internationalization

All the messages discussed above, should have possibility of being presented as simply string or externalized strings for internationalization.

messages (for element)

The messages for specific element could be displayed next to an input element. The annotation would simply denote the id of the element, as shown below.

<tr>
   <th class="rightLabel">
			<label for="categoryName">Category Name</label>
					<font color="red">*</font>
   </th>
	<td align="left">
		<input type="text" name="categoryName" value="">
	</td>
	<td>
       <!-- aws:element type="messages" id="categoryNameValidator" -->
			Category Name is required.
       <!-- /aws:element -->
   </td>
</tr>

The messages elements represent messages for the page as well as for a single element. Whenever an id attribute is specified, the message that pertains to the identified element is specified to show.

The implementation depends on the validation specifications. It is within such specification that the messages are stipulated. Since multiple validators could be involved, the issue of layout needs to be considered. For such consideration, check the element descriptor validator attribute.

The implementation of the sample specification shown above is implemented below.

<tr>	
	<th class="rightLabel">		
		<asp:Label AssociatedControl="categoryName" runat="server"			
			Text="Category Name" />		
		<font color="red">*</font>	
	</th>	
	<td align="left">		
		<asp:TextBox ID="categoryName" runtat="server"			
			Text='<%# Bind("CategoryName" %>' />	
	</td>	
	<td>		
		<asp:RequiredFieldValidator 			
			ID="RequiredFieldValidator2" runat="server"			
			Text="Category Name is required"
			ControlToValidate="categoryName"
			EnableClientScript="false"/>
	</td>
</tr>

messages (for page)

This messages element captures the various ways most platforms would provide text messages for display on the page view.

The representation in the content source is with annotations.

  <!-- aws:element type="messages" value="error" -->  		
      <!-- mock presentation could be included here -->  
  <!-- /aws:element -->

These annotations would be placed in the source content. There is no need for corresponding entry in the descriptors. Other descriptor specifications could influence the final implementation. Example is the form descriptor attributes, like server or client validations enabled attributes of the form descriptor.

Within the annotations would be the mock representation of the messages. The value would be as recognized on the platform. For example, some platforms have message categories like error, info, warning, debug, etc.

The position of the representation outside a form, would dictate that the message is for the page, whereas within a form, it is for the specific form.

The implementation on ASP.NET platform is through the ValidationSummary control, which is used to display a summary of all validation errors occurring on a page.

These error messages displayed are accumulated from each of the validation controls. The following are the properties that could be used to customize the display.

Properties