On 5/4/06, Bob Lee <[EMAIL PROTECTED]> wrote:
- Passing in keys vs. actual messages - I think always passing in keys is one thing Struts got right.
I presume you meant Struts Action Framework 1 ;-)
Even if you only support one language, abstracting messages out of your code is still a good practice.
Passing actual message is a nice-have for quick projects or for intranet one-language projects.
- I didn't like having the same set of methods twice: one for errors and one for regular messages. The new design is more object oriented, has shorter method names, enables better reuse of code between errors and normal messages, and leaves the door open to other levels of messages (such as warning). I'm not saying we want to explicitly support arbitrary levels (like JSF does), but we don't want to close the door to it either.
Is it possible to assign different prefixes to messages generated by different actions? This may be helpful if a page contains several components, each component is controlled by its own action (or a set of actions), so when a component is updated in Ajax mode (or the whole page is reloaded) the messages will be displayed in the proper places. I mean, every component should display only its own messages.
- In the old design, messages were scoped to an action which doesn't work very well when you're chaining and you want to display all the errors from all the actions. I think we want messages to be scoped to the request (i.e. spanning multiple actions). We actually use our own message handling and ignore WebWork's at the moment.
SAF1 already have had messages request-scoped. This does not work for Redirect-after-post stuff, so SAF1 now has session-scoped messages, that are removed from the session automatically after they are displayed. This is kind of FlashScope for poor. I suggest to have a real FlashScope for messages and other stuff. This may have less importance if WW UI will be Ajax only. Also, considering that in WW action and actionform is one thing, I would say that action-scoped messages are better: messages and actual data that was validated, are stored at the same place. Messages belong to a particular data set of a particular component (action). I experimented with ActionForm-scoped messages in SAF1, having session-scoped ActionForms. Works well in terms that when you reload the page, here is your invalid data, and here are the corresponding errors. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
