DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26668>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26668 errors messages tags enhancement: make them show only errors/messages ------- Additional Comments From [EMAIL PROTECTED] 2004-02-05 19:08 ------- OK, I can see a case for wanting form.validate() to return two types of messages. However, the intention which many existing applications build upon is that validate returns *errors*. I would be hesitant to change that so that it returns a mix of messages and errors. For example, the RequestProcessor takes the presence of a non-empty return from validate as an instruction to skip the action and instead forward to the input page. But my idea of messages is that they wouldn't be the kind of thing you'd want to abort processing for. So now the RequestProcessor also needs to be changed if the ActionErrors object returned from ActionForm.validate() may have non-errors in it. In any case, the ActionError/ActionErrors classes are deprecated -- they aren't intended to distinguish errors from messages, they just reflect an earlier design decision (oversight) to think of errors as the only kind of messages. So using the *type* of elements in an ActionMessages wouldn't be the right way to achieve what you want. ActionForm returns ActionErrors only for backwards compatibility. I could see perhaps adding a "getMessages()" method to ActionForm, and indicating that the "validate" process my implicitly populate an ActionMessages which would be returned from that method. I'm not sure I'm crazy about this solution, but perhaps it's a path to pursue. Presumably any ActionForm which can make messages as well as errors is a custom class -- validator doesn't know how to do that -- if that's the case, you could implement the above without requiring a change to the core Struts ActionForm semantics. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
