Not sure if there's a best practice here but it makes it easier when Actions use constants when putting objects in a scope.
David
From: "Hohlen, John" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: "Struts-Help (E-mail)" <[EMAIL PROTECTED]>
Subject: Best Practice: Organizing Bean Key & Error Key Constants?
Date: Thu, 7 Nov 2002 11:09:21 -0600
Are there any best practices on how to organize all the bean key and error
key constants that created when implementing a Struts application? I'm
assuming most people create String constants for the name of keys used to:
1) store/retrieve bean data to/from application and session scope
2) error messages from the application resources file.
My project currently puts all their bean key constants in their own package
for a module. For example:
public final class BeanConstants {
public static final String SALESPERSON_DEFAULT_PLAN_NAME_KEY =
"planassociations.salespersonDefaultPlanName";
public static final String SALESPERSON_CURRENT_PLAN_ID_KEY =
"planassociations.salespersonCurrentPlanId";
...
}
Are others creating classes like this or are they just hard-coding the key
names when needed? The use of constants helps guard against typos when a
bean key is used in multiple places. Obviously, a hard-coded string will
always compile, so a typo won't be detected until run-time (e.g. bean not
found error). In addition, with this approach, are others importing the
"BeanConstants" class in their JSP so they can reference the constant
instead of hard-coding the string in the JSP as well? My project doesn't
allow any Java scriplet code in their JSPs, but this might become our only
exception.
Finally, where are you defining the keys for error messages? Are you using
constants or just hard-coding them? If you're using constants for the error
keys, are they in the action or an "ErrorKeyConstants" class (similar to the
bean key constants class above). In some cases, the same error key (or
message) will be used by multiple actions.
I looked in some of the new Struts books (Ted Husted's & Chuck Cavaness') as
well as the mailing lists and didn't really see much on this topic. Most
code examples use the hard-coded String approach for brevity purposes.
Thanks,
JOHN
--
To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>