On Tue, Nov 16, 2010 at 4:27 PM, Vjeran Marcinko <vjeran.marci...@email.t-com.hr> wrote:
> Not sure I quite understood you, but... Hope to be more clear... > I don't say there is no easy workaround for this - use ValidateForm and > return "this", although one could argue that "validateForm" isn't the right > name for method where one doesn't validate anything, just wants to execute > service layer operation and catch possible exception. "success" handler > seems as the right place for calling service logic since all form validation > passed fine, doesn't it (error is not due to form validation, but service > error)? Walking these fields of discussion is almost always unproductive where anyone can have it's own way of thought, for example, db data constraints where belongs? Doesn't belongs to where I validate data submitted? > But lingering question remains why any workaround is needed for something > that is normal in 99% of cases (having fields inputs seen again when staying > on same page), and not having workaround for something that is unusual > (clearing input fields when staying on same page)? Oh well... my mileage may vary quite a lot, and others can say the same too... I find the situation perfectly suites my needs. I've never had the needs to stay on the same page and show the form (plus with editable fields) after a successful form iteration... After a successful form submission you somehow save the data and then you have the data so there's no need to keep them up in the ValidationTracker. Isn't it? Cheers -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
