Which submit button did I click?

I’d go for event.currentTarget, would save you some code

@chenroth I got your point… but since we are using the form submit event, the event.currentTarget will be the form again, not the clicked button… or may be I’m missing something here… would you mind explain how we can optimize this?

oh, there’s no optimization here - the practice of using 2 submit buttons in one form is unforgivable and beyond repair :smile:

I was just making a general comment that e.currentTarget would always be a more specific targeting (or at the least the same) compared to e.target

in this case, e.currentTarget and e.target both return the form element

Why is everybody against multiple submit buttons?
How else could I implement:

  • add, subtract, divide or multiply entered numbers
  • delete or make private selected tasks
  • I am sure the list can go into infinity

don’t use forms.
forms are a primitive tool for grouping data before sending it over HTTP
Meteor doesn’t do that, which means you don’t really need forms

as for HTML5 form validation, my opinion is it’s not good enough and requires custom script validation anyway, so there goes the validation benefit

also, forms may not even be semantically correct anymore - why would i want a form to represent a calculator app (borrowing your add/subtract/divide/multiply example)

2 Likes

So without onsubmit it would be like @nlammertyn suggested

HTML

  <form class="authenticate"       id="authenticate">
    Username: <input type="text"   id="username"                 /> <br>
    Password: <input type="text"   id="password"                 /> <br>
              <input type="button" value="Create" class="create" />
              <input type="button" value="Login"  class="login"  />
  </form>

Event

"click .create": function(event, t){
  
  //Authenticate.
  var username = authenticate.username.value;
  var password = authenticate.password.value;
        
  //Create user.
  Accounts.createUser( {username:username, password:password} );

},    

Although he used second parameter of event handler

t.$("form.authenticate input[name=username]").val();

Don’t know if that is needed. When I simply use authenticate.username.value is Meteor looking for id="authenticate" only in the template where the event occurd?

1 Like

well, a few points here:

  1. authenticate.username.value works as long as you use forms. I believe you already know my opinion about forms, so I’d use the browser’s native document.querySelector or jQuery’s $ method

  2. @nlammertyn suggested using the template instance $ method, which reduces the selector scope to elements within the template (and probably has better performance, but I don’t have a proof of that)

  3. I’d refrain from using the element’s class attribute to define functionality. the class attribute is used for style and shouldn’t be mixed with logic; i personally use a “data-action” attribute

1 Like