[ajacksified]

I'm not so sure; I have to agree with heme. "ui-keypress="{13:'keypressCallback($event)'}" seems a whole lot like the UI is specifying behavior (on key 13, call a function called keypressCallback). This is no different than [pseudocode] "onkeydown='if(e.key==13){ keypressCallback(e) }" with a slightly cleaner syntax, except that you're calling it on an arbitrary this instead of the window. It's just as dirty. The event bindings belong in the js, not the html.

[enoren]

In my brief experience with Angular the difference is that while you can do "ui-keypress="{13:'keypressCallback($event)'}" that is more of the lazy way of doing things. The benefit of using the View and the way it should be used is in a declarative form such that someone looking at the View can know immediately that some element has some interactive behavior attached to it, but the proper way is to abstract it via a directive so that you don't pollute your view with the imperative details.

So, instead of using

<input "ui-keypress="{13:'keypressCallback($event)'}">

where keypressCallback does a form submit or something, you would write a directive that is just "form-submitter" and you would have your DOM be

<input form-submitter >

So that way you can easily scan your view to see what elements have what behaviors, but not how.

And Angular also allows you to bind events within javascript and really that is what the "form-submitter" directive in this example would be doing as well, but it should not be happening in general within the view/dom.

Although many times it is too heavy weight to make a directive for everything, but that is where the scope concepts of Angular comes in as well as the controllers so that at least the functions that are being triggered are still more expressive as they are localized to the containing scope. So, for instance you could have a directive "my-form" which is just an enhancement of the standard html form. In my directive I can then define a "validate()" method which validates the inputs. So, instead of having a "form-validator" directive I can instead do:

<my-form> <input type="text" >

  <button ng-click="validate()"/>

</my-form>

Because of the scoping rules of Angular it is generally easier to infer the behavior of the method that is being called as it is scoped to my-form and as long as you are playing by the best practices there is not any real concern for functionality within that method to leak outside of "my-form" thus maintaining the ability to look at the DOM and have a pretty good idea of what the application is doing without digging through javascript as well.

[ajacksified]

That makes more sense. I disagree with the general principle of defining javascript actions by using properties like "form-submitter" or "validate()". I think that there is more than enough room in html5 to define an entire application without writing attributes specifically for binding, but that's the point of Angular- being able to easily bind to a view, which you can't do easily otherwise.

Thanks for the explanation! That helped shed some light.