client-side form validation with ng-messages.

[rhutchison]

Add validation on the client to validate form data prior to posting to the server.

[ilanbiala]

@rhutchison @lirantal not directly about the PR itself but I think we need to add to 0.5.0 conventions another item about refactoring all of the Angular code to remove the data- prefix. That was only necessary for XHTML and it just makes the code longer and seems unnecessary.

If you guys agree, then we should already start enforcing that with new PRs and refactor the rest before we release next time. We could even do it for 0.4.x because it wouldn't break anything, it's just a style change really.

[rhutchison]

@ilanbiala I agree with removing it, but I would like to do a single PR for that. We can do it before this is merged or after - up to you guys.

[mleanos]

+1 on removing the data- @rhutchison About when to remove it, I don't think it's detrimental either way. I think encouraging (enforcing) this style change right now, for any new PR's, could be helpful though.

[mleanos]

LGTM. I've tested this, and it works really well. I really like the implementation, as it's easy to add to any form.

I would like to share a possible limitation, or tricky use case though...

I tried playing around with ng-messages by adding validation to the Chat Example. This didn't function quite right. The sendMessage() method clears out the messageText field, after a successful form submit, and the ng-messages validation see's this as an invalid form. I fiddled with it quite a bit, and couldn't get it to function properly. However, I do realize that the Chat Example isn't a very good use case for this feature; the submit button here should be disabled unless the form is valid. For most use cases, ng-messages seems to work really well. It might be tricky when you have a form that can have an empty field after a valid form submit. Perhaps, this is something to watch out for.

Overall, this feature really enhances the UI. Thanks @rhutchison

[ilanbiala]

@rhutchison if possible enforcing for all new PRs will be best, and then 1 PR at the end before a release to fix all the existing/remaining ones so we don't have to keep rebasing and doing that stuff like we had to do with the spacing PR.

[rhutchison]

closing to reopen/rerun test

[rhutchison]

@ilanbiala

[ilanbiala]

I'll have to review when I'm at a computer. If I don't get to this in a week or so, just remind me because I'm on vacation for the next week and I probably won't be near a computer.

[codydaig]

Once data- is put back in for consistency (at least for this PR), it will LGTM.

[lirantal]

so are we in favor of removing data-* or keeping it?

[ilanbiala]

I'm in favor of removing.

[codydaig]

+1 for removing.

[rhutchison]

Closes/supersedes #247

[mleanos]

+1 for removing data-

[mleanos]

Just tested this with the most recent changes.. Everything seems to be working.

LGTM.

[lirantal]

Good, thanks.