It's perfectly Ok, to record your own cross-field validation errors in the delegate. At least as long as you can associate the error sensibly with a particular (set of) field (s).
I use an error display component in my @Border, which actually checks two different sources for errors. The first is the validation delegate for form-related stuff, the second is a Message-property of the page which is an adapter for "normal" messages and exceptions from the lower layers like "optimistic lock broken" or "Nothing matches your search criteria" which bear little logical relation to a particular field. > -----Original Message----- > From: Balachandran [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 04, 2007 4:14 AM > To: users@tapestry.apache.org > Subject: Re: Error Message Handling > > > > But what I am trying to acheive is a uniformity in displaying > all messages to the user.I am using a dojo dialog to display > validation error messages.I would like to use the same for > these kinds of exceptions also. > > > Dennis Sinelnikov wrote: > > > > For runtime/unexpected exceptions, you can specify an > Exception page > > via your .application spec to tell tapestry to use this page. > > > > <page name="Exception" specification-path="Exception.page"/> > > > > You can add more dynamic logic to this page, to display > user-friendly > > messages depending on the exception thrown. > > > > hth, > > dennis > > > > > > -- > View this message in context: > http://www.nabble.com/Error-Message-Handling-tf2912986.html#a8153255 > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
