[Struts Tip #17] Don't settle for <html:errors/>

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 <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 renditions.

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

This is all fine and dandy if you just want to print 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.

Struts Tips are based on excerpts from the book Java Web Development 
with Struts. <http://husted.com/struts/book.html>

The tips released weekly on the MVC-Programmers List. To subscribe, 
visit BaseBean Engineering. <http://basebeans.com/>

About Ted. Ted Husted is an active Struts Committer and co-author of 
Java Web Development with Struts and Professional JSP Site Design. Ted 
also moderates the Struts mailing list and the JGuru Struts FAQ.

Copyright Ted Husted 2002. All rights reserved.

###

_______________________________________________
MVC-Programmers mailing list
[email protected]
http://www.netbean.net/mailman/listinfo/mvc-programmers