Gotcha. That's the part I figured out. It looks now like it wasn't the ILink
thing, but rather the fact that the code was getting executed because I
didn't circumvent it.
On 2/18/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
>
> there is no difference between listeners that return X or Y - it only
> changes what will happen next...
> BUT - notice that listener code is executed regardless of validtion
> errors. If you want a listener to execute only when no errors are there
> you must add a small
> if (getValidationDelegate().getHasErrors()) return null;
> at the beginning...
> cheers,
> ROn
>
>
> Drew McAuliffe wrote:
> > Looks like I answered my own question. I set up a property on my page to
> > hold a ValidationDelegate (using "initial-value"; I found this easier to
> > work with in code than accessing a bean, though I could use a bean if I
> have
> > my own validation delegate that needs props set). I set the prop in the
> page
> > spec, then point my form at it.
> >
> > My method now looks something like this:
> >
> > public ILink save()
> > {
> > if (getDelegate() != null && getDelegate().getHasErrors())
> > return null
> > // normal save code
> > return someILinkValue;
> > }
> >
> > That seems to work pretty well and should be guaranteed to pick any
> > validation errors without a hassle.
> >
> > I still am curious, though: do listeners that don't return ILink
> > automatically do this kind of check anyway?
> >
> > On 2/17/06, Drew McAuliffe <[EMAIL PROTECTED]> wrote:
> >
> >>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]
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
