As far as keys, I just use getMetaData. Also, most of my primary keys are called ID and auto generated by db as sequence for high load support.
hth, .V
Hohlen, John wrote:
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>
