Don't settle for ＜html:error＞

Many Struts applications can get by with a simple

<html:error/>

tag at the top of a page. If any error messages are present, it's this tag's job to print them all out. To help prettify the output, <html:error> checks for errors.header and errors.footer messages in the application resources. If found, the tag prints these before and after the block of messages. A common setup is:

errors.header=<UL> 
errors.footer=</UL>

Struts 1.0 developers can then include <LI> and </LI> tags with the text of each message to used this way. In Struts 1.1, the situation improves with the addition of the errors.prefix and errors.suffix messages. Just as the header and footer print before and after the block of messages, the prefix and suffix print before the individual messages. So to print a simple list of any message that might arise, you can just include

errors.header=<UL> 
errors.footer</UL> 
errors.prefix=<LI> 
errors.suffix=</LI>

in your application resources, and the (Struts 1.1) <html:error> tag will take care of the rest.

Though, many purists would complain that HTML markup has no place in a message resources file. And they would right. Even with the Struts 1.1 prefix and suffix feature, you may still need to use different markup different pages.

For Struts 1.0 applications, the Struts Validation extension (see the Struts Resource page) offers a useful alternative to the standard <html:error/> tag. You can use these tags whether you are using the rest of the validator package or not. Instead of providing one omnibus tag, the validator approach is to use an iterator to expose each message, and then leave it up to the page to provide whatever other formatting is necessary. Here's an example:

<validator:errorsExist> 
<UL>
 <validator:errors id="error"> 
 <LI><bean:write name="error"/></LI>
 </validator:errors> 
</UL> 
</validator:errorsExist>

In Struts 1.1, these tags were adopted into the core taglibs. Here's the same example using the Struts 1.1 rendition.

<logic:messagesPresent> 
<UL>
 <html:messages id="error"> 
 <LI><bean:write name="error"/></LI>
 </html:messages> 
</UL> 
</logic:messagesPresent>

This is all great if you just want to print your messages as a batch. But many messages are related to data-entry validation and involve a specific field. Many page designs expect a message concerning a field to printed next to a field.

Not a problem. When the error message is queued, you can specify a "property" to go with it. If you don't specify a property (using any of the tags we described), then all the messages print. If you do specify a property, then only the messages queued for that property print.

The default code for queuing an error message is:

errors.add(
  ActionErrors.GLOBAL_ERROR, 
  new ActionError("error.username.required")
);

To specify that this message is for the "username" property, we would code this instead:

errors.add(
  "username", new ActionError("error.username.required"));

If we specify a property, we can use the <html:errors/> tag (or any of the alternatives) like this:

<P>Username: <html:text property="username"/></P> 
<P>Password: <html:password property="password"/></P>

The "username" errors print next to the username field, and any "password" errors print next to the password field.

But what if you need to print both specific and general errors?

Again, no problem. You can also specify the "generic" property just like you did in the Java code. First, at the top of your JavaServer Page import the Action and ActionErrors package so you can reference the appropriate constants:

<%@ page import="org.apache.struts.action.Action" %> 
<%@ page import="org.apache.struts.action.ActionErrors" %>

Then in the tags, use a runtime expression to specify the constants:

<logic:present name="<%=Action.ERROR_KEY%>"> 
<P><html:errors property="<%=ActionErrors.GLOBAL_ERROR%>"/></P> 
</logic:present>

Viola! Specific messages print out in specific places, and any "general" errors can still print out in a place of their own.

Of course, you don't have to settle for any of these standard tags. If these variations still don't meet your specific needs, take a peek at the source code and cobble up your own! The framework provides the queue, but how it prints is up to you.

HTH, Ted.