For review

[Ron Piterman <rp...@gmx.net>]

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

Re: For review

[Nick Westgate <ni...@key-planning.co.jp>]

Hi Ron.

This has already been logged against LinkSubmit:
http://issues.apache.org/jira/browse/TAPESTRY-339

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:
http://www.tapestrycomponents.org/Tassel/app?service=external/ViewComponent&sp=SLinkSubmitOrSpan

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.

Cheers,
Nick.


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