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/
> 

Reply via email to