StrutsCX controls the validation of input errors exclusively inside the Action class. The settings in the ActionMapping conform more or less with the ones of Struts. Inside the ActionForm object nothing really changes: If errors occur an ActionErrors container filled with ActionError objects gets returned by the validate() method. But: The method add() of the ActionErrors object does need a Struts ActionMessage object. Albeit StrutsCX does not use this object, it is added:

// code-snipped of Struts FormBean:
public ActionErrors validate(ActionMapping mapping, 
                             HttpServletRequest request) {
  ActionErrors errors = new ActionErrors();
  if (title == null || title.length() < 1) {
    errors.add("title", // name of HTML input field
    new ActionError("anything")); // any ActionMessage object
  }
  return errors;
}

Picture 5: Activity diagram for the examination of the ActionErrors container inside the Action.

By calling the validate() method of the ActionForm object the Action class gets hold of the ActionErrors container with its ActionError objects.

// code-snipped of Struts Action:
ActionErrors errors = actionForm.validate(mapping, request);

If its filled, the ActionErrors container will get added to the HttpServletRequest and forwarded to the ERROR target defined inside the struts-config.xml. If the ActionErrors container is empty, the HttpServletRequest gets forwarded to the SUCCESS target defined inside the struts-config.xml.

// Action code continued:
if (!errors.empty()) {
  request.setAttribute("errors", errors);
  forward = "ERROR";
} else {
  forward = "SUCCESS";
}

Of course additional ActionError objects can be added to the ActionErrors container inside the Action classes. There is no restriction to the validation of user input. During XSLT transformation all these error objects become incorporated into the XML-Output-Document so they can be used by the XSL Stylesheet. Here's an extract out of a XML-Output-Document:

<root>
  ...
  <variables>
  ...
    <!-- error message strings -->
    <errors>
      <title>Bitte einen Titel angeben!</title>
      ...
    </errors>
    ...
  </variables>
  ...
  <!-- error flags -->
  <errors>
    <title/>
    ...
  </errors>
  ...
</root>

Inside the XSL-Stylesheet this information can be used to compose an appropriate error message:

<!-- show error message if error tag is present -->
<xsl:if test="/root/errors/title = node()">
  <div class="error">
    <xsl:value-of select="/root/variables/.../errors/title"/>
  </div>
</xsl:if>
<textarea name="title" rows="2" cols="30" style="width=250px">
  <xsl:value-of select="title"/>
</textarea>

The code of the XSL Stylesheet is very similar to the use of a JSP Tag: The goal is to show the error message just in case the xsl:if statement is true, that means an error Element exists inside the XML-Output-Document. The validation is done by a XPath Node Test. The text of the error message is part of the XML-Output-Document, too. Originally its part of the StrutsCX-Resources-Properties file.

Picture 6: Multi-language error messages with StrutsCX. The display of asian languages is no problem any longer.