RE: ErrorsTag (was /contrib)
Since you are making changes in this area how about also extending the ActionError class so that it can hold an exception if one has been thrown? What I want to do when a serious problem occurs is to divert to an error page, display a friendly error message and write details of the problem as an html comment. I can do this at the moment by storing the Exception in the request but it would be more convenient if it was part of the ActionError, particularly if there is more than one. -Original Message- From: David Winterfeldt [mailto:[EMAIL PROTECTED]] Sent: 12 July 2001 06:33 To: [EMAIL PROTECTED] Subject: Re: ErrorsTag (was /contrib) I checked in the changes I've made. There is an html:messages tag that iterates through the errors and is basically the same as the tag I had in the validator class except for the changes that were discussed. I've made an ActionMessages class and ActionMessage class. ActionErrors now extends ActionMessages and ActionError extends ActionMessage, but should work the exact same (basically the code from the errors classes is just in the parent). My thinking was that an error is basically a more a specific type of message. I haven't added the messagesExist tag yet because I'm not sure where it belongs. All the logic tags are very generic. Maybe it belongs in a taglib/validator package. If you read this Craig, maybe you could comment. David --- Ted Husted [EMAIL PROTECTED] wrote: David Winterfeldt wrote: This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. I'm just thinking that the default messages would be errors, but you could also use the same tags for general messages by supplying another id, for example the Action.MESSAGE_KEY. So errors are just the default messages, but you can use the same tags for managing any other message queues desired, just by supplying a message id (and/or alternate headers and footers). Alternatively, the tag could take a switch like messages=true to use the MESSAGE_KEY key. The default could be messages=false, which would use the standard ERROR_key. To be consistent, we would use messagesExist with the same properties, and let it default to the ERROR_KEY. This leaves the html:errors as it is, and makes the message tags a new series with more functionality, that use the old ERROR_KEY by default, but can be used with other queues as well. -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
I checked in the changes I've made. There is an html:messages tag that iterates through the errors and is basically the same as the tag I had in the validator class except for the changes that were discussed. I've made an ActionMessages class and ActionMessage class. ActionErrors now extends ActionMessages and ActionError extends ActionMessage, but should work the exact same (basically the code from the errors classes is just in the parent). My thinking was that an error is basically a more a specific type of message. I haven't added the messagesExist tag yet because I'm not sure where it belongs. All the logic tags are very generic. Maybe it belongs in a taglib/validator package. If you read this Craig, maybe you could comment. David --- Ted Husted [EMAIL PROTECTED] wrote: David Winterfeldt wrote: This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. I'm just thinking that the default messages would be errors, but you could also use the same tags for general messages by supplying another id, for example the Action.MESSAGE_KEY. So errors are just the default messages, but you can use the same tags for managing any other message queues desired, just by supplying a message id (and/or alternate headers and footers). Alternatively, the tag could take a switch like messages=true to use the MESSAGE_KEY key. The default could be messages=false, which would use the standard ERROR_key. To be consistent, we would use messagesExist with the same properties, and let it default to the ERROR_KEY. This leaves the html:errors as it is, and makes the message tags a new series with more functionality, that use the old ERROR_KEY by default, but can be used with other queues as well. -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
--- Ted Husted [EMAIL PROTECTED] wrote: Craig R. McClanahan wrote: Following this philosophy, we'd create a new tag (perhaps html:messages?) for the new functionality, and deprecate html:errors. In addition, we'd need to change the 1.1 implementation of html:errors so that it did something sensible, even in the face of a new and improved error messages object. The Validator package actually includes a general messages tag, which isn't much different from its errors tag. So maybe we should just add that one, and have it start by using the default ERRORS key. I believe people could then also use it for other messages just by specifying a different id property, and a different header or footer, if desired. I think all we would have to do is add an optional property property to messages and messagesExist. This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. Where would the messagesExist tag go? David http://home.earthlink.net/~dwinterfeldt/jsptags.html -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: ErrorsTag (was /contrib)
This sounds good. I adding 'messages=true'. That makes it easier to use than have to put in a long key each time. David --- Ted Husted [EMAIL PROTECTED] wrote: David Winterfeldt wrote: This would work, but would it be confusing for a general message tag to default to errors? Originally when I did this I was thinking that for general messages there could be ActionMessage, ActionMessages, Action.MESSAGE_KEY, etc. And there would still be the equivalent ones for errors, but they would subclass the general message ones and use Action.ERROR_KEY. I'm just thinking that the default messages would be errors, but you could also use the same tags for general messages by supplying another id, for example the Action.MESSAGE_KEY. So errors are just the default messages, but you can use the same tags for managing any other message queues desired, just by supplying a message id (and/or alternate headers and footers). Alternatively, the tag could take a switch like messages=true to use the MESSAGE_KEY key. The default could be messages=false, which would use the standard ERROR_key. To be consistent, we would use messagesExist with the same properties, and let it default to the ERROR_KEY. This leaves the html:errors as it is, and makes the message tags a new series with more functionality, that use the old ERROR_KEY by default, but can be used with other queues as well. -Ted. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
