AngularUI for AngularJS
angular-ui.github.com
angular-ui.github.com
Can someone explain why this:
<input ui-event="{ blur : 'blurCallback()' }">
<input onblur="blurCallback();" />
If you're talking about the general idea of binding events in HTML, they are the same, but combined with Angular's design the choice has a lot of advantages. From the docs (http://docs.angularjs.org/guide/concepts):
"The separation of the controller and the view is important because:
1. The controller is written in JavaScript. JavaScript is imperative. Imperative is a good fit for specifying application behavior. The controller should not contain any rendering information (DOM references or HTML fragments).
2. The view template is written in HTML. HTML is declarative. Declarative is a good fit for specifying UI. The View should not contain any behavior.
3. Since the controller is unaware of the view, there could be many views for the same controller. This is important for re-skinning, device specific views (i.e. mobile vs desktop), and testability."
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()"/>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.
Thanks for the explanation! That helped shed some light.
As I understand, Angular is its team's vision on how browsers will natively support client-side apps in the future, in which case there will probably be a more streamlined syntax for such things.
It prescribes a lot of things in terms of how your application is structured. Some people come just looking to use one specific feature of angular and get overwhelmed by it all.
But I stuck it out, and got some apps working with it, and it truly is amazing. You do have to go "All-in" with angular, but once you do, its amazing. The way it glues your app together really does make you a better/faster web app designer.
I've never been able to work out why.
There's a large (but a bit messy) example here: http://plnkr.co/edit/7FhBFN?p=preview
I love big examples like this for making choices about what the next big framework should be. It gives a real feel for how the framework behaves in real life. I must say, even with the custom tags and ng-parameters, this still looks very very readable and organized.
https://github.com/jhiemer/angularjs-calendar
Feel free to contribute!
None of these elements work with Javascript disabled. Would sure be great to support simple clients and use Javascript features only to enhance the experience.
So many sites are becoming unusable without Javascript for seemingly very little benefit
However, "Therefore there is no need for progressive enhancement" is also wrong - there is. That's why they use "title" for tooltips, a textarea for code boxes, etc.
The tiny calendar then doesn't look anything like the big one, it uses an entirely different gradient and radius for the rounded corners and looks more like jQuery UI.
Like I said it's cool and I appreciate work like this, but a good UI should probably involve good UI fundamentals.
That calendar is easy to fix with a little CSS, I have used it. Lack of pixel perfect polish in an example's styling = lack of UI fundamentals, really?
A 'shiv' is a knife. Despite all its faults, IE never stabbed anyone.