But I shouldn't even get to my new page unless my listener code has executed, which shouldn't be the case if validation fails, right? Otherwise, I'm executing a save or add and then getting back to the validation error. The problem isn't with the fact that redirection loses a delegate, I don't think; there's no way around losing a request-scoped variable after a redirect without storing it somewhere else. The problem, I think, is that when returning ILink, something about validation isn't getting picked up that circumvents the listener code, which I believe it does when you have a void return on your listener.
On 2/17/06, Ron Piterman <[EMAIL PROTECTED]> wrote: > > I would think you loose your validation delegate on the way. > The new activated page has a new delegate, without any errors. > Cheers, > ROn > > > Drew McAuliffe wrote: > > I am attempting my first go at the new Tapestry validation and seem to > have > > run into a problem. The vast majority of the pages in my app have > listeners > > that return a valid ILink, instead of a void signature. According to the > > tapestry docs, this is to do a redirect after submit, which is what I > want > > (the users insist upon the redirect-after-post pattern, to avoid browser > > refresh issues). > > > > The problem is, if there's a validation error, it won't get caught when > > returning an ILink. My listener ends up processing as if nothing was > wrong > > when there's a validation error. If I replace my listener code with a > simple > > "return null;", then if there's a validation error, it will be marked > > appropriately. > > > > Is there a way built into the validation framework to handle it? Though > I > > may be missing something (and I've checked all of the docs I could find) > It > > seems like it doesn't work when a listener returns ILink. Because of > > popularity of the redirect-after-post pattern, I would imagine that this > > would not be an "edge" case. Maybe there's some kind of usage of > delegates > > or listeners or something that I'm missing? > > > > Thanks, > > > > Drew > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
