Thanks for all your help! I see what you mean, we do use the form validation in a lot of places, but mainly only for mandatory stuff. I'll look into what I can easily do to get this kind of logic in, it certainly applies to the immediate problem I was having.
It's still not always applicable. For example, we have a search results page where a number of finance agreements are listed after the user has searched for them. The user can then choose to select one of these (using a normal <a> link, but in certain circumstances selecting it will cause an exception to be raised. (We have replaced the tapestry exception page with a more customer friendly page for when our specific exceptions are raised, and left the tapestry one in for everything else. Hopefully we won't get tapestry's error page in production!) There is no form here, so we can't use ValidationDelegate, we just show the exception page, and allow the user to go back. Thanks again, Tim. On Thursday 24 August 2006 20:04, Ron Piterman wrote: > Me again... > > Two things: the exception page is not for business logic exceptions but > should be used as a fallback in case of dev mistakes (also known as > bugs) and in case someone tempers with your application and sends wrong > information in the URLs. > > Tapestry's Form handling is one of the framework's best and most mature > features, which , imho, makes this framework so important. If you don't > use it - you miss a great feature. > > Cheers, > Ron > > Tim Sawyer wrote: > > Thanks Ron. In this case, that's fine I can add that in. > > > > In other cases it's just not possible. I have a 700,000 line Java > > business layer behind my front end, there are going to be all sorts of > > exceptions cropping up. It doesn't make commercial sense to write all > > that validation in the front end. > > > > Does anyone know why the original problem I outlined occurs? Is tapestry > > doing some validation on the form submit to ensure it is not double > > submitted? > > > > Ta, > > > > Tim. > > > > On Thursday 24 August 2006 14:21, Ron Piterman wrote: > >>Use validation instead of a custom exception page, this will solve your > >>problem and be more useable, since the user can correct the problem on > >>the same page where the error message apeared. > >> > >>Cheers, > >>Ron > >> > >>Tim Sawyer wrote: > >>>hi, > >>> > >>>I have a tapestry page which displays a text entry field for each item > >>> in an array. These fields are for entering cheque numbers, and there > >>> is also an Activate button. If activate is pushed whilst one of the > >>> cheque number fields is blank, then I (correctly) get an exception > >>> raised - "all cheque numbers must be entered" This is shown to the > >>> user using a custom exception page. > >>> > >>>Here's where my problems start. If I now click back on the exception > >>>page (which does a javascript:history.back()), fill in the missing > >>> cheque number, and then click Activate again, the newly entered cheque > >>> number does not get through to the model behind the array of cheque > >>> number fields. > >>> > >>>Does anyone have any idea why? Or any pointers as to where to look? > >>> > >>>Cheers, > >>> > >>>Tim. > >>> > >>> > >>>--------------------------------------------------------------------- > >>>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] > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
