You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jonathan O'Connor <Jo...@xcom.de> on 2004/09/30 12:37:07 UTC

Re: SubmitListener [auf Viren geprueft]

Eric,
After getting into lots of trouble with using listeners attached to each 
button, I have changed our forms to have a single form submit. All the 
buttons use selected="ognl:buttonPressed" tag="buttonName" stuff. Then in 
my listener, I do something like:

public void formSubmit(IRequestCycle cycle) {
        if ("button1".equals(getButtonPressed()) handleButton1(cycle);
        else if ("button2".equals(getButtonPressed()) 
handleButton2(cycle);
}

Of course, this is a bit ugly, and the style Police will surely kill me 
for it, but its very safe code. When we have listeners directly attached 
to each button, we had to be very careful not to add or remove rows from a 
ForEach table. The reason: button listeners are executed before rewinding 
has completed. The form listener only runs after rewinding, so its safe to 
change collections then.

Occasionally, we have to break our rule, and actually write a button 
listener. E.g. In a table, each row might have a delete button. In this 
case, the button listener remembers which row was selected, and sets the 
buttonPressed property to "deleteRow", which is then handled in the normal 
way in our form submit.

Hope this helps,
Jonathan O'Connor
XCOM Dublin



Eric Fesler <er...@audaxis.com> 
30/09/2004 07:42
Please respond to
"Tapestry users" <ta...@jakarta.apache.org>


To
tapestry-user@jakarta.apache.org
cc

Subject
SubmitListener [auf Viren geprueft]






Hi,

I 'm a newbie with Tapestry and I recently came into what seems to be a
classical issue.

I have a page with Submit components and listener for that components.
Depending upon the position of the Submit components (at the beginning
of the form or at the end of the form) I hved a completely different
behavior.

Looking deeper, I found that it was due to the fact that submit listener
are triggered at the time the component is rewind and that explained the
problem.

I looked for some discussions on the subject and I found the following
page on the wiki.
http://tapestry.sourceforge.net/wiki/index.php/Developer%20Issues
This page mentions that "Howard initiated a discussion on how the
listeners could be improved to make their use more natural to
developers." but there isn't any pointer to such a discussion.

Is there any place where I could find discussion to this issue?

I'm looking for a way to be able to trigger different actions (based on
the clicked button or image) *after* the form has been fully rewind.

Any suggestions?

Thanks,

--ERic



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



Re: SubmitListener [auf Viren geprueft]

Posted by Eric Fesler <er...@audaxis.com>.
Hi Jonathan,

thanks for you reply.

I though to a solution similar to yours but I wanted to find a more
generic model.

Finally, I extended the standard Form and Submit component and when
rendering the form during the rewind process I trigger the new listeners
(I called them PostFormListener) of the extended Submit component.

It's little bit tricky but it works.

--ERic

On Thu, 2004-09-30 at 12:37, Jonathan O'Connor wrote:
> Eric,
> After getting into lots of trouble with using listeners attached to each 
> button, I have changed our forms to have a single form submit. All the 
> buttons use selected="ognl:buttonPressed" tag="buttonName" stuff. Then in 
> my listener, I do something like:
> 
> public void formSubmit(IRequestCycle cycle) {
>         if ("button1".equals(getButtonPressed()) handleButton1(cycle);
>         else if ("button2".equals(getButtonPressed()) 
> handleButton2(cycle);
> }
> 
> Of course, this is a bit ugly, and the style Police will surely kill me 
> for it, but its very safe code. When we have listeners directly attached 
> to each button, we had to be very careful not to add or remove rows from a 
> ForEach table. The reason: button listeners are executed before rewinding 
> has completed. The form listener only runs after rewinding, so its safe to 
> change collections then.
> 
> Occasionally, we have to break our rule, and actually write a button 
> listener. E.g. In a table, each row might have a delete button. In this 
> case, the button listener remembers which row was selected, and sets the 
> buttonPressed property to "deleteRow", which is then handled in the normal 
> way in our form submit.
> 
> Hope this helps,
> Jonathan O'Connor
> XCOM Dublin
> 
> 
> 
> Eric Fesler <er...@audaxis.com> 
> 30/09/2004 07:42
> Please respond to
> "Tapestry users" <ta...@jakarta.apache.org>
> 



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