tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Westgate <n...@key-planning.co.jp>
Subject Re: For review
Date Wed, 02 Nov 2005 09:55:14 GMT
Hi Ron.

This has already been logged against LinkSubmit:

Howard recently claimed a dupe of this bug, so it's possible the
required one line fix might make it into the next beta I suppose.
(I'm not using T4 yet though ...)

As far as T3 is concerned, Aslak is not correct about all submits
being affected by this. IIRC only LinkSubmit (in T3) uses a hidden
field in this way - which causes the bug. See LinkSubmitOrSpan:

I agree with Aslak that the hidden field should be able to be used
by other components if need be - not just an internal feature of
LinkSubmit alone.


Ron Piterman wrote:
> Taken from the user list
> (title: Fundamental form submit problem?, author: Aslak Gronflaten)
> Might be important...
> Cheers,
> Ron
> ========================================================================
> Hi,
> I'm not sure if there is a technique to circumvent this problem,
> but I feel tapestry handles this the wrong way.
> If I have a page with a form with a default listener,
> and two LinkSubmit components, each with its own listener.
> When I click either of the links, a hidden field is sat on the form,
> (called LinkSubmit  or LinkSubmit_0 respectively) with the value "T".
> This indicates which of the links is clicked, and tapestry makes sure
> the correct listener is called.
> However, if these listeners cause proceeding to a new page,
> then clicking Back in the browser gives problems.
> The browser then remembers the value of those hidden fields,
> causing the wrong listener to be called when submitting again.
> In .net, for example, there is only one hidden variable, called event
> source or something like that. Clicking link one sets that variable to
> "one", thus overwriting whatever the browser remembers. Also, every
> component that causes a submit has this behaviour. A dropdown that
> causes a submitOnChange must also reset those variables, or we get the
> wrong behaviour.
> Try this example:
> <form jwcid="@Form" listener="listener:one">
>     <a jwcid="@LinkSubmit" listener="listener:two">Two</a><br/>
>     <a jwcid="@LinkSubmit" listener="listener:three">Three</a><br/>
>     <input jwcid="@Submit" label="literal:One"/><br/>
> </form>
> If each listener logs its name out, you'll see that clicking Three
> prints "Three" then "One", as expected.
> Click Back, then press One, and it'll still print "Three" then "One".
> Not just One, as it should.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message