For the 99.9% of the situations I agree with you Jim, but when you do some kind of generic subsystem to reuse across applications it's very possible to need such behavior. Here might be arguable that such situations can be avoided, but still... you might end up presenting messages that are much too general to the user.
At 17:53 21.12.2004, you wrote:
> -----Original Message----- > From: Woodchuck [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 21, 2004 8:23 AM > To: struts > Subject: ActionMessage replacement "keys" ? > > > hihi all, > > is everyone rolling their own helper function to use other > message keys > as replacement values when creating ActionMessage or ActionError > objects? > > i'm wondering if there's a better way to do this other than > getting the > MessageResources object and calling the getMessage() function then > putting the results into an object array and then passing this to the > ActionMessage constructor... > > can/will this functionality be added to the ActionMessage > object in the > future?
If you're talking about building a message using other keys, no. I generally find that I am better off using a seperate key for such situations. The problem I run usually into is one of syntax, especially with other languages. Breaking things up like that can make it harder to structure a well formed sentence. Since one of my pet peeves is messages that are not grammatically correct, I avoid this at all costs.
Consider an English message translated into say German. IIRC there is a joke about a German teacher who ends every class with 5 minutes of verbs. Apparently German verb structure is different then English, so how would fit that structure into your messages? Or Navajo, which is completely different from any other language?
Such flexibitlity in your messages might be nice from a programming standpoint, but could be a major pain when translating into foreign languages.
So, my answer to your question is that I don't use message resource keys as arguments to my messages. In such cases I just use a different message key for each possibilty.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
