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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
