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/
