need not-submitting button

[Garret Wilson <ga...@globalmentor.com>]

Everyone,

There needs to be a way to have a Button that does not perform an HTML 
submit, such as Link, which allows onClick() handling instead of onSubmit().

Your first response will probably tell me to RTFM and 
setDefaultFormProcessing(false). :) But hear me out. If I have a submit 
button <button wicket:id="cancel" type="submit"...> in the HTML, and set 
an <input> as required in the HTML, then modern browsers will be so nice 
as to pop up a little flyover bubble pointing right at the field in 
question, and say, "You need to fill in this field." The problem is that 
the cancel button <button wicket:id="cancel" type="submit"...> will also 
cause this browser response, even with setDefaultFormProcessing(false) 
in the code, because the browser does this validation before submission 
even occurs.

I can short-circuit browser validation on cancellation by using <button 
wicket:id="cancel" type="reset"...> in the HTML, but then my 
Button.onSubmit() code in Java won't get called!

I can work around this by using Link in the code instead of Button, 
using <button> with type="reset" in the HTML, and overriding onClick() 
in the Java code. But it seems strange (and semantically silly) to use a 
Button in one instance and Link in another, just to get different submit 
activity---that is, unless all Wicket Buttons are really SubmitButtons.

In fact, that's what I'm getting to: a Button is a button, and it should 
have an onClick() method just like a link. Only a specialized 
SubmitButton should have an onSubmit(). A normal Button shouldn't cause 
automatic submission of the form just because I used a Button instead of 
a Link.

You may say that I should turn off required in the HTML so as to disable 
all browser validation, and let Wicket take care of all validation for 
consistency. There is some validity to this, but the flyover 
notifications the browser uses for empty required fields are so pretty 
and so much more user-friendly...

Garret

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: need not-submitting button

[Garret Wilson <ga...@globalmentor.com>]

On 7/9/2014 11:11 PM, Martin Grigorov wrote:
> There are three types of HTML buttons: submit, reset and button. You need
> the third one: <button type="button">Like Link</button>.

Ah, yes---I was a little HTML-rusty and the "button" type slipped my mind.

Unfortunately, using type="button" my Button.onClick() method still does 
not get called. Only when I change it to type="submit" does my 
Button.onClick() method get called.

For now I'm going to turn off the "required" attributes and let Wicket 
do all the validation on the server side, which in this case is probably 
better, anyway. But I still think it is a Wicket shortcoming that does 
not allow a Button to receive input from a <button> unless the <button> 
is set to submit so that the browser thinks the form will be submitted, 
even if Wicket decided to skip form processing on the server side. A 
Button click should be able to be detected regardless of whether it 
submits the form or not in the HTML, in my opinion.

Cheers,

Garret

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: need not-submitting button

[Martin Grigorov <mg...@apache.org>]

Hi,

There are three types of HTML buttons: submit, reset and button. You need
the third one: <button type="button">Like Link</button>.
See http://www.w3schools.com/tags/att_button_type.asp

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov


On Thu, Jul 10, 2014 at 4:03 AM, Garret Wilson <ga...@globalmentor.com>
wrote:

> Everyone,
>
> There needs to be a way to have a Button that does not perform an HTML
> submit, such as Link, which allows onClick() handling instead of onSubmit().
>
> Your first response will probably tell me to RTFM and
> setDefaultFormProcessing(false). :) But hear me out. If I have a submit
> button <button wicket:id="cancel" type="submit"...> in the HTML, and set an
> <input> as required in the HTML, then modern browsers will be so nice as to
> pop up a little flyover bubble pointing right at the field in question, and
> say, "You need to fill in this field." The problem is that the cancel
> button <button wicket:id="cancel" type="submit"...> will also cause this
> browser response, even with setDefaultFormProcessing(false) in the code,
> because the browser does this validation before submission even occurs.
>
> I can short-circuit browser validation on cancellation by using <button
> wicket:id="cancel" type="reset"...> in the HTML, but then my
> Button.onSubmit() code in Java won't get called!
>
> I can work around this by using Link in the code instead of Button, using
> <button> with type="reset" in the HTML, and overriding onClick() in the
> Java code. But it seems strange (and semantically silly) to use a Button in
> one instance and Link in another, just to get different submit
> activity---that is, unless all Wicket Buttons are really SubmitButtons.
>
> In fact, that's what I'm getting to: a Button is a button, and it should
> have an onClick() method just like a link. Only a specialized SubmitButton
> should have an onSubmit(). A normal Button shouldn't cause automatic
> submission of the form just because I used a Button instead of a Link.
>
> You may say that I should turn off required in the HTML so as to disable
> all browser validation, and let Wicket take care of all validation for
> consistency. There is some validity to this, but the flyover notifications
> the browser uses for empty required fields are so pretty and so much more
> user-friendly...
>
> Garret
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>