The general interpretation of this attribute allows demarcation portion of data entry screen into groups. The common use of this involves validation groups. For instance, the elements involved in the credit card entry would be validated separately from the order line entries. This could imply that the order could be modified and saved with the click on the save button. Or else, credit card entered and pay button clicked. The save button should not cause validation of the credit card entries; in most cases this could cause validation errors. The order elements would be in one validation group, and the credit card in another.

The implementation of specification groups could be achieved with custom programming; what is described here is what is available out of the box for Struts.

Struts does not provide in-built facilities for validation groups in the general sense. What this attribute is applicable to are wizards.

There is common pattern of placing a full set of elements on the page, of which sub-sets are exposed for entries, base on a sequence number.  Struts has an elegant solution that allows these groups validations to be based on their sequence number.

For the implementation this group-id (page number) would be assigned to the validation specifications as shown below.

  <form name="categoryForm">
	  <field property="categoryName" depends="required" page="1">
		  <arg0 key="categoryForm.categoryName.label"/>
	  </field>
  </form>
  

This topic is also discussed in the form descriptor section, under the attribute of sequence-numb. The distinction to make with the sequence-numb is that when this is statically defined, it places all elements on the page on the same validation group. When this sequence is determined dynamically, then multiple groups could exist on the page, that could be enable, made visible and validated base on the current sequence-numb matching their group-id.