DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.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://issues.apache.org/bugzilla/show_bug.cgi?id=26668 errors messages tags enhancement: make them show only errors/messages --- Additional Comments From [EMAIL PROTECTED] 2004-03-26 15:51 --- For easy access, here is a direct link to bug 27384. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.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://issues.apache.org/bugzilla/show_bug.cgi?id=26668 errors messages tags enhancement: make them show only errors/messages --- Additional Comments From [EMAIL PROTECTED] 2004-03-09 00:56 --- Partially for one of my own projects, and partially in response to this, I submitted 27384, which targets this issue from another direction. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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-08 15:20 --- I have implemented 4 classes of messages. Of course to actually achieve this with the current flow of control was a bit of a contortion but I believe it is the complete set of message handling. 1) Validation errors which force entry of new data. 2) Validation messages which are informational in nature, i.e. an unusual piece of information was entered, but was not necessarily invalid. 3) Post validation errors which force entry of new data (i.e. database errors). 4) Post validation messages, i.e. the successful commit. The use case is if you don't want a special page for success but would rather re-use the same page but give an indication of the success. Edgar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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-07 17:54 --- Interesting... and backwards compatible. Would you give severity an implied ranking, so that the messages tag would show all messages of the given severity or higher? Or would severity be more like a classification system, so that you'd show exactly the messages of the given severity? I had thought that html:errors was deprecated, although I see that it isn't officially marked so. We've been trying to prune out stuff that is ancient history so that there aren't several ways to do the same thing. Should it be deprecated? One hitch I see is that you'd really need a method like messages.size(severity), but assuming that severity is a String, you'd have a collision with the existing messages.size(property). Maybe Severity should be an integer -- that would make a ranking system more straightforward, although perhaps at the risk of clarity. I don't particularly have a use case for this, but it sounds like it would be possible to implement it in a way that I wouldn't object to. Other committers might have strong feelings about changing something so central. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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-07 18:56 --- Here is the use case. The form bean's validate method reports validation errors along with messages. The errors would include the standard messages from validation rules (defined in validation.xml) and some additional rules that are defined programmatically in the validate method. The example of the message would be You have entered the DOB that makes you 120 years old. Or You indicated that your weight is 900 pounds. In other words, it might not be an error but it's an unusual value and something that would be nice to get a verification for. The verified data then submitted to the action (using verification flag that is an attribute of the form). From controller stand point there is no difference - if form reports either error or message I do not want to proceed any further. From presentation stand point, I'd like to show the messages in a way different from errors. If we would implement the severity attribute, it can be achieved relatively easy: !-- show errors using errors tag-- html:errors severity=10 / !-- OR show errors using mesages tag-- html:messages severity=2 header=errors.header footer=errors.footer bean:write name=message/ /html:messages !-- show messages using mesages tag-- html:messages severity=2 header=messages.header footer=messages.footer bean:write name=message/ /html:messages Note 1. I thought about severity more like a classification system but if it has to be an integer then the other option you mentioned might have a value. I'm not sure how we could make it work with implied ranking though. Second messages tag will print all of the errors then. Note 2. Severity should probably be initialized with 10 (or 0 if we want the most critical one to have a minimal number) so the errors from the standard validator could be shown. Note 3. I'm not sure that method messages.size(severity) is required since the tag could still return the size of the whole collection but severity attribute could be used as a filter in the loop. If we could get away with this then I'd rather make the severity a string. But you are definitely more familiar with code so I trust you on that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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-07 19:12 --- I think this adds unneeded complexity to messages. All you need to do to get both messages and errors is to validate the data in the Action. Many applications handle form verification this way to allow the exception handling mechanism kick in (which isn't possible in ActionForm.validate()). In my experience, complex validation logic is best handled in an Action because it handles talking to the database and branching scenarios far better than validate(). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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-07 19:24 --- I wrote most of this while David was making his post, so I'll just adapt it: I meant I haven't needed it more than I can't imagine the use case. However, I think you point out an implementation question -- I wouldn't assume that warnings (as opposed to errors) are always cause to return the user to the input form; that would need to be configurable. Some people might want errors to return to the input form, while messages would be displayed on the normally following page. Also, if you warn and return them to the input form, how does a user indicate that they are choosing to ignore the warning and bypass the loop? This was one of the kinds of things that was generally on my mind for needing a messages.size(severity) method, and I think it also touches on David's point -- this might be more clearly handled in the Action itself. This sounds like something that you should try for yourself and see just how complex it is. If you come up with a solution that you think is really good, well -- you've got the solution already. You can attach patches to this bug ticket and see if committers think that it adds useful functionality without too much complexity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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-07 00:12 --- I believe that the best solution could be to add the severity attribute to the ActionMessage class and to both errors and messages tags. That way the ActionMessage/ActionError can be created with a specific severity and then the errors/messages tag's severity attribute can be used to show different groups of messages based on the severity level. What do you think about that ? I can make the changes if the concept makes sense. Should not be a big deal and is in line with existing design. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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 17:21 --- Because it’s not a convenient way to separate errors and messages in the action _FORM_. The ActionForm is the class that I'm taking about not the Action class. In particular, the validator subclass ValidatorForm that has a validate() method. That method returns a collection of errors. With the changes I proposed it would be possible to add the ActionMessage instances to the errors collection and then show errors and messages separately. Methods saveErrors() and saveMessages() are defined in the Action class. If I'd use them I'd have to move part of the validation outside of the form's validate method, where it's all encapsulated nicely, into the action w/out any sound reason. Alternatively, there could be another validateXXX() method added to the ValidatorForm that would be executed after existing validate() and return a collection of ActionMessage instances that would be set in the request the same way as saveMessages() does in Action class. Regardless, I do not agree that moving validation logic out of the form's validate method (if it can be done there) to the Action just because of the limitations in the framework is a good answer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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 [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26668] - errors messages tags enhancement: make them show only errors/messages
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-04 19:57 --- You write Note. There is currently a message attribute in the html:messages tag but it’s not a convenient way to separate errors and messages in the action form. but you don't specify why that isn't convenient. It works for many developers now. What's inconvenient for you? You are clear on the distinction between saveErrors() and saveMessages() in the Action class, yes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
