You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Geoffrey Wiseman <ge...@gmail.com> on 2009/04/24 02:21:22 UTC
Tapestry Forms and Cancel Button
I like my forms to have cancel buttons. Tapestry BeanEditor forms don't
have them. There are some options, each with some problems. I've been
reading a bunch of other threads on the subject, and thought I'd summarize
some of the options and issues here.
*Submit Button*
The most common approach for a cancel button outside of Tapestry would be a
second submit button. In tapestry, you can do this -- you add a second
button, give it a separate id, then in the triggered event, set a flag,
blah blah blah. That's basically what the submit component page describes:
http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/Submit.html
That works, although it's a little more work than I would like. The real
problem hsere is client-side validation. Client-side validation gets
triggered when the form is submitted regardless what clever trickery you
have on the server side. So if you don't want that to happen, you have a
couple of options: do some client-side
trickery<http://markmail.org/thread/5kxf7abviyicj5gd>of your own to
disable javascript validation when the server-side form is
submitted, or use a link instead.
*Using a Link*
This <http://markmail.org/message/x7xra2zhe6heqpin> works fine from a
functionality perspective. It just doesn't look visually consistent. You
can wrap the link around an image or one of a number of buttons done with
CSS, Javascript, etc. As long as these don't use <button> tags internally,
they'll work, but it often means you'll need to change all of the buttons in
your application to match. If you were already considering custom buttons,
this is probably the best way to go.
*Using a Link with a Button Inside*
I tried using a link with an HTML button inside, as was described
here<http://markmail.org/message/o2qom7zm45atymoo>,
and it had an interesting effect. I haven't tracked down exactly what
happens between the browser and the server, but it can cause pretty severe
and subtle issues. I was using this 'til I hit this snag. Basically,
tapestry first treats this like a submitted form, then goes on to process
the link. This seems to involve triggering client side validation, server
side validation, server-side success and finally page navigation. Near as I
can tell from jetty logs, The form is getting POSTed and the link is being
clicked, both. Not sure if this behaves the same way in all browsers.
I initially used this for a cancel, and it was working fine -- except I
discovered almost accidentally that if the content of the form was valid, it
got saved to the database. Basically, when the content was invalid, it
would trigger validation, fail, then move on to the desired page. Ugly, but
largely irrelevant, save for the slightly odd behavior that you could
sometimes catch client-side Javascript failing before the page switched.
However, when the content of the form was valid, the success method was also
triggered, thus writing the data to the database when the cancel button is
hit. This is far worse, and something you might miss -- I had, for several
days.
I could disable the client-side validation, but this wouldn't fix the
server-side problem. I could move the cancel button outside of the form
element (outside a form, or in another
form<http://markmail.org/message/kwyqzh5o6lonmam6>)
to retain the button look-and-feel, but then I'd need to do some tricksy CSS
work to get the button to appear side-by-side with the submit button, where
I want it to be. Probaby quite doable, but not really what I'm looking
for. I could also skip that step, and just have the submit and cancel
buttons appear in different places, which would be a little odd, but would
solve the problem.
So, in summary, the options that feel reasonable to me are:
- No client-side validation, and submit buttons for both submit and
cancel.
- Custom buttons across the app using images or css, as long as these
don't trigger the same issue.
If there are other options to consider, fire away so that they're in the
thread.
- Geoffrey
--
Geoffrey Wiseman
http://www.geoffreywiseman.ca/
Re: Tapestry Forms and Cancel Button
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Sat, Apr 25, 2009 at 3:06 PM, Marcus Veloso <mv...@gmail.com>wrote:
> Another option?
>
> ...
> <t:form t:id="cancelForm">
> <t:submit value="Cancel">
> </t:form>
> ...
>
>
> void onSubmitFromCancelForm() { ... }
>
I included that one:
> I could move the cancel button outside of the form element (outside a
> form, or in another form <http://markmail.org/message/kwyqzh5o6lonmam6>)
> to retain the button look-and-feel, but then I'd need to do some tricksy CSS
> work to get the button to appear side-by-side with the submit button, where
> I want it to be. Probaby quite doable, but not really what I'm looking
> for. I could also skip that step, and just have the submit and cancel
> buttons appear in different places, which would be a little odd, but would
> solve the problem.
>
It's not a /bad/ option, it's just a little more CSS work to make it appear
part of a single consistent form layout, given default CSS. Presumably
doable (I haven't tried, but CSS makes HTML layout pretty dang flexible, so
I'm assuming it could be done), but it does more damage to the page layout
than I'd ideally like. It's probably not my first choice, although perhaps
if I tried it, I might find it's less work than I imagine it to be.
Are you going this route? Do you bring the cancel button into a single form
layout with CSS?
- Geoffrey
--
Geoffrey Wiseman
http://www.geoffreywiseman.ca/
Re: Tapestry Forms and Cancel Button
Posted by Marcus Veloso <mv...@gmail.com>.
Another option?
...
<t:form t:id="cancelForm">
<t:submit value="Cancel">
</t:form>
...
void onSubmitFromCancelForm() { ... }
Re: Tapestry Forms and Cancel Button
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Thu, Apr 23, 2009 at 8:21 PM, Geoffrey Wiseman <
geoffrey.wiseman@gmail.com> wrote:
> *Using a Link with a Button Inside*
> I tried using a link with an HTML button inside, as was described here<http://markmail.org/message/o2qom7zm45atymoo>,
> and it had an interesting effect. I haven't tracked down exactly what
> happens between the browser and the server, but it can cause pretty severe
> and subtle issues. I was using this 'til I hit this snag. Basically,
> tapestry first treats this like a submitted form, then goes on to process
> the link. This seems to involve triggering client side validation, server
> side validation, server-side success and finally page navigation. Near as I
> can tell from jetty logs, The form is getting POSTed and the link is being
> clicked, both. Not sure if this behaves the same way in all browsers.
>
Had a thought last night -- this is Redirect After Post again. Post goes
in, gets a 302, then fires a GET. Jetty logs confirm.
- Geoffrey
--
Geoffrey Wiseman
http://www.geoffreywiseman.ca/
Re: Tapestry Forms and Cancel Button
Posted by Geoffrey Wiseman <ge...@gmail.com>.
On Thu, Apr 23, 2009 at 11:18 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> What about:
>
> .tml:
>
> <button onclick="window.location='${cancelURL}'; return
> false;">Cancel</button>
>
> .java:
>
> @Inject
> private ComponentResources resources;
>
> public String getCancelURL() {
> return resources.createEventLink("cancel").toAbsoluteURL();//or you
> could inject the service for creating page links and create a regular page
> link...
> }
>
> public Object onCancel() {
> //now you have a chance to do any cleanup work you want to do.
> return "otherpage";
> }
Not horrible if Javascript is turned on. If it's turned off, this'll
presumably submit the form. I forgot to summarize that one, although I did
see a couple people recommending that as an option.
- Geoffrey
--
Geoffrey Wiseman
http://www.geoffreywiseman.ca/
Re: Tapestry Forms and Cancel Button
Posted by Robert Zeigler <ro...@scazdl.org>.
What about:
.tml:
<button onclick="window.location='${cancelURL}'; return
false;">Cancel</button>
.java:
@Inject
private ComponentResources resources;
public String getCancelURL() {
return resources.createEventLink("cancel").toAbsoluteURL();//or
you could inject the service for creating page links and create a
regular page link...
}
public Object onCancel() {
//now you have a chance to do any cleanup work you want to do.
return "otherpage";
}
I just did a quick test, and this works nicely, even allowing you the
opportunity to clean up your form when you're done.
Robert
On Apr 23, 2009, at 4/237:21 PM , Geoffrey Wiseman wrote:
> I like my forms to have cancel buttons. Tapestry BeanEditor forms
> don't
> have them. There are some options, each with some problems. I've
> been
> reading a bunch of other threads on the subject, and thought I'd
> summarize
> some of the options and issues here.
>
> *Submit Button*
> The most common approach for a cancel button outside of Tapestry
> would be a
> second submit button. In tapestry, you can do this -- you add a
> second
> button, give it a separate id, then in the triggered event, set a
> flag,
> blah blah blah. That's basically what the submit component page
> describes:
> http://tapestry.apache.org/tapestry5/tapestry-core/ref/org/apache/tapestry5/corelib/components/Submit.html
>
> That works, although it's a little more work than I would like. The
> real
> problem hsere is client-side validation. Client-side validation gets
> triggered when the form is submitted regardless what clever trickery
> you
> have on the server side. So if you don't want that to happen, you
> have a
> couple of options: do some client-side
> trickery<http://markmail.org/thread/5kxf7abviyicj5gd>of your own to
> disable javascript validation when the server-side form is
> submitted, or use a link instead.
>
> *Using a Link*
> This <http://markmail.org/message/x7xra2zhe6heqpin> works fine from a
> functionality perspective. It just doesn't look visually
> consistent. You
> can wrap the link around an image or one of a number of buttons done
> with
> CSS, Javascript, etc. As long as these don't use <button> tags
> internally,
> they'll work, but it often means you'll need to change all of the
> buttons in
> your application to match. If you were already considering custom
> buttons,
> this is probably the best way to go.
>
> *Using a Link with a Button Inside*
> I tried using a link with an HTML button inside, as was described
> here<http://markmail.org/message/o2qom7zm45atymoo>,
> and it had an interesting effect. I haven't tracked down exactly what
> happens between the browser and the server, but it can cause pretty
> severe
> and subtle issues. I was using this 'til I hit this snag. Basically,
> tapestry first treats this like a submitted form, then goes on to
> process
> the link. This seems to involve triggering client side validation,
> server
> side validation, server-side success and finally page navigation.
> Near as I
> can tell from jetty logs, The form is getting POSTed and the link is
> being
> clicked, both. Not sure if this behaves the same way in all browsers.
>
> I initially used this for a cancel, and it was working fine --
> except I
> discovered almost accidentally that if the content of the form was
> valid, it
> got saved to the database. Basically, when the content was invalid,
> it
> would trigger validation, fail, then move on to the desired page.
> Ugly, but
> largely irrelevant, save for the slightly odd behavior that you could
> sometimes catch client-side Javascript failing before the page
> switched.
> However, when the content of the form was valid, the success method
> was also
> triggered, thus writing the data to the database when the cancel
> button is
> hit. This is far worse, and something you might miss -- I had, for
> several
> days.
>
> I could disable the client-side validation, but this wouldn't fix the
> server-side problem. I could move the cancel button outside of the
> form
> element (outside a form, or in another
> form<http://markmail.org/message/kwyqzh5o6lonmam6>)
> to retain the button look-and-feel, but then I'd need to do some
> tricksy CSS
> work to get the button to appear side-by-side with the submit
> button, where
> I want it to be. Probaby quite doable, but not really what I'm
> looking
> for. I could also skip that step, and just have the submit and cancel
> buttons appear in different places, which would be a little odd, but
> would
> solve the problem.
>
> So, in summary, the options that feel reasonable to me are:
>
> - No client-side validation, and submit buttons for both submit and
> cancel.
> - Custom buttons across the app using images or css, as long as
> these
> don't trigger the same issue.
>
> If there are other options to consider, fire away so that they're in
> the
> thread.
>
> - Geoffrey
> --
> Geoffrey Wiseman
> http://www.geoffreywiseman.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org