You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jer Kah <je...@gmail.com> on 2004/11/01 21:11:33 UTC
Submitting forms
Hi,
I don't know if any of my speculation is true or not, so please
correct me where I am wrong....
I have a page with 2 forms - one with all my data collection elements
( datePicker, dropdowns, etc) and the other simply has a submit
button. I have a feeling that this _should_ be one form, but the
reason I have split this up is so I can easily distinguish between
when I want my page to be refreshed and when it is actually submitted.
I have a series of dropdown boxes on the first form that have a
'cascading' effect between them so I need to know when to refresh the
page so I can get the new, updated values for the dropdowns without
submitting everything. This part works fine. The part that causing
me pains is that I also have a textfield on the form, and sometimes it
gets submitted when I hit the submit button and sometimes it doesn't.
After playing around with it, I figured out why - it works so long as
I enter data into the textbox and THEN change any dropdown ( because
this causes the page to be refreshed (i.e. form #1 to be
'submitted')) but it doesn't work if I enter data into the textfield
after selecting my values for the dropdowns.
The simplest thing I can think of to get this to do what I want is
to be able to 'force' the first form to be submitted when the submit
button (which is on form 2) is pushed. Is there a way of forcing
this?
I know this stinks of newbie hackery (hey, I've been using
Tapestry for 2 weeks), so my question is: what's the proper way to do
this? If it's to make this one form, what's the 'best practice' using
Tapestry to distinguish between refreshing and submitting?
Thanks,
Jer
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Submitting forms
Posted by Jer Kah <je...@gmail.com>.
Thanks for the suggestions. The bit about the button being before the
component wasn't an issue in my case (the button was the last thing on
the page), but the strategy as described at
http://wiki.apache.org/jakarta-tapestry/FrequentlyAskedQuestions/SubmitListener
is working perfectly for me.
-----------------------------
I don't know if anybody (mainly other newbies) really care, but here
is what I was doing and what I am doing now....
I had 2 forms on one page - the first one to collect data via
textboxes, dropdowns, etc. The second form simply had a submit
button. I specified the first form with a listener called formRefresh
and I set the dropdown boxes' submitOnChange property to true. The
second form had a listener called formSubmit which was obviously only
called when the button was pushed.
The problem I had was that if I entered text into a textbox on form #1
and then pushed the submit button on form #2, the textbox value was
never submitted. (FYI, if I entered text into a textbox and then
changed a dropdown, it _would be_ submitted due to the submitOnChange
value being true, thereby submitting the entire form, including the
textbox).
The solution is to put it all in one form and having a listener called
submitListener. Then, define your submit button (and any other
button, such as Update, Reset, Cancel) as
<input jwcid="Insert@Submit"
selected="ognl:submitListener"
tag="ognl:listeners.formSubmit"
value="Submit" />
Simply make sure the selected property is "ognl:submitListener" and
the tag property pointing to whatever listener method you want in your
code.
(You can read about the details of this at
http://wiki.apache.org/jakarta-tapestry/FrequentlyAskedQuestions/SubmitListener.)
Then, as described at the wiki, you have to create the method submitListener as:
public void submitListener(IRequestCycle cycle) {
IActionListener submitListener = getSubmitListener();
if (submitListener != null) {
submitListener.actionTriggered(null, cycle);
setSubmitListener(null);
}
}
The last line above ( setSubmitListener(null); ) isn't listed in the
code at the wiki page, but I found that it needs to be there (at least
in my case - my app is all on one page so I need to clear any
IActionListeners so I can continue doing refreshes and such).
Instead of each button, form, etc pointing to it's own listener, the
idea is to make all the submissions go through the submitListener
method. If the submitListener object in the code above is null, then
nothing else will get called and you have yourself a refresh.
Otherwise, the property listener method (as defined by your "tag"
property) is called.
Ok, I hope I didn't accidentally say anything about Tapestry's
internals that is wrong and I hope that this helps at least someone
out.
Thanks again for your help.
Jer
On Tue, 02 Nov 2004 19:16:09 +0900, Nick Westgate
<ni...@key-planning.co.jp> wrote:
> 15 years of C/C++ programming makes me flinch at the idea of using a
> function call rather than an assignment to set a flag. But then writing
> Tapestry apps is dancing on so many layers of magic; I have to remember
> to forget about such things.
>
> As for Struts, I remain blissfully unaware of its internals. My current
> employer was generous enough to let me choose a framework for a project.
> Struts seemed like yesterday's news. With the ServerSide.com surprise,
> Tapestry is looking less like tomorrow's and more like today's news. ;-)
>
> But the learning curve is steep. Although confident in the choice of
> framework, for the first week I was reading, the second week I was
> sweating, and the third finally saw progress. Some of the questions on
> this list seem to involve ambitious projects; I wonder how many managers
> are willing to wait for weeks to see significant progress.
>
> Cheers,
> Nick.
>
>
>
>
> Erik Hatcher wrote:
>
> > Another technique that is useful for multi-button forms is to still have
> > a listener on each button, which sets a flag on which was clicked. The
> > @Form listener then keys off the flag indicating which button was
> > pressed. Certainly less than ideal, but could be worse, you could be
> > using LookupDispatchAction in Struts :) [I'm the original author of
> > LDA, by the way - yes, it's nobody's fault but mine]
> >
> > Erik
> >
> >
> > ---------------------------------------------------------------------
> > 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-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Submitting forms
Posted by Nick Westgate <ni...@key-planning.co.jp>.
15 years of C/C++ programming makes me flinch at the idea of using a
function call rather than an assignment to set a flag. But then writing
Tapestry apps is dancing on so many layers of magic; I have to remember
to forget about such things.
As for Struts, I remain blissfully unaware of its internals. My current
employer was generous enough to let me choose a framework for a project.
Struts seemed like yesterday's news. With the ServerSide.com surprise,
Tapestry is looking less like tomorrow's and more like today's news. ;-)
But the learning curve is steep. Although confident in the choice of
framework, for the first week I was reading, the second week I was
sweating, and the third finally saw progress. Some of the questions on
this list seem to involve ambitious projects; I wonder how many managers
are willing to wait for weeks to see significant progress.
Cheers,
Nick.
Erik Hatcher wrote:
> Another technique that is useful for multi-button forms is to still have
> a listener on each button, which sets a flag on which was clicked. The
> @Form listener then keys off the flag indicating which button was
> pressed. Certainly less than ideal, but could be worse, you could be
> using LookupDispatchAction in Struts :) [I'm the original author of
> LDA, by the way - yes, it's nobody's fault but mine]
>
> Erik
>
>
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Submitting forms
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Nov 2, 2004, at 3:06 AM, Nick Westgate wrote:
> 2) Understand that form processing occurs in the same order as
> defined in the HTML template.
>
> So form components _after_ a submit button in the HTML get updated
> _after_ the submit button's listener gets called. This is a good
> reason to use only one form with a form submit listener, and to use
> "selected" and "tag" to indicate which submit was clicked. If the
> "selected" object is null, then it was a javascript
> (PropertySelection 'refresh' etc) submit.
Another technique that is useful for multi-button forms is to still
have a listener on each button, which sets a flag on which was clicked.
The @Form listener then keys off the flag indicating which button was
pressed. Certainly less than ideal, but could be worse, you could be
using LookupDispatchAction in Struts :) [I'm the original author of
LDA, by the way - yes, it's nobody's fault but mine]
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Submitting forms
Posted by Nick Westgate <ni...@key-planning.co.jp>.
Hi Jer (and tapestry-users).
I'm a Tapestry, Java and webdev newbie, but this kind of question
is exactly what I came up against when learning Tapestry recently.
Tapestry is way cool, and the folks on this list are very helpful.
But somebody (not me, naturally ;-) could improve the FAQ on this.
Some kind of Tapestry best practices list for newbies.
Anyway, one of the guru's here will probably give a great answer,
but here is mine:
1) Read the FAQ about Submit, and also Gotcha #4:
http://wiki.apache.org/jakarta-tapestry/FrequentlyAskedQuestions
http://wiki.apache.org/jakarta-tapestry/Gotchas
2) Understand that form processing occurs in the same order as
defined in the HTML template.
So form components _after_ a submit button in the HTML get updated
_after_ the submit button's listener gets called. This is a good
reason to use only one form with a form submit listener, and to use
"selected" and "tag" to indicate which submit was clicked. If the
"selected" object is null, then it was a javascript
(PropertySelection 'refresh' etc) submit.
3) Buy "Tapestry In Action", the PDF version. It's a good book, but
much valuable information is scattered throughout various chapters.
Acrobat's find function becomes invaluable.
Cheers,
Nick.
Jer Kah wrote:
> Hi,
> I don't know if any of my speculation is true or not, so please
> correct me where I am wrong....
>
> I have a page with 2 forms - one with all my data collection elements
> ( datePicker, dropdowns, etc) and the other simply has a submit
> button. I have a feeling that this _should_ be one form, but the
> reason I have split this up is so I can easily distinguish between
> when I want my page to be refreshed and when it is actually submitted.
> I have a series of dropdown boxes on the first form that have a
> 'cascading' effect between them so I need to know when to refresh the
> page so I can get the new, updated values for the dropdowns without
> submitting everything. This part works fine. The part that causing
> me pains is that I also have a textfield on the form, and sometimes it
> gets submitted when I hit the submit button and sometimes it doesn't.
> After playing around with it, I figured out why - it works so long as
> I enter data into the textbox and THEN change any dropdown ( because
> this causes the page to be refreshed (i.e. form #1 to be
> 'submitted')) but it doesn't work if I enter data into the textfield
> after selecting my values for the dropdowns.
>
> The simplest thing I can think of to get this to do what I want is
> to be able to 'force' the first form to be submitted when the submit
> button (which is on form 2) is pushed. Is there a way of forcing
> this?
>
> I know this stinks of newbie hackery (hey, I've been using
> Tapestry for 2 weeks), so my question is: what's the proper way to do
> this? If it's to make this one form, what's the 'best practice' using
> Tapestry to distinguish between refreshing and submitting?
>
> Thanks,
> Jer
>
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org