Create build for other modules as well (ngResource, ngCookies):
- wrap into a function
- add license
- add version
Breaks `$sanitize` service, `ngBindHtml` directive and `linky` filter were moved to the `ngSanitize` module. Apps that depend on any of these will need to load `angular-sanitize.js` and include `ngSanitize` in their dependency list: `var myApp = angular.module('myApp', ['ngSanitize']);`
this was never meant to be a public api used by apps. I refactored
the code to hide the functionality.
BREAKING CHANGE: $browser.addJs method was removed
apps that depended on this functionality should either use many of the
existing script loaders or create a simple helper method specific to the
app.
this api was never supposed to be public. nobody should be relying
on it.
I'm removing it since angular doesn't need it.
BREAKING CHANGE: $browser.addCss was removed
apps the depend on this functionality should write a simple utility
function specific to the app (see this diff for hints).
closure compiler is stubborn and puts the flag to the top of the file, so
we have to post-process the minified file to move the flag into the angular
closure.
Previously one had to write:
$routeProvider.when('/foo', {...});
$routeProvider.when('/bar', {...});
$routeProvider.otherwise({...});
After this change it's just:
$routeProvider.
when('/foo', {...}).
when('/bar', {...}).
otherwise({...});
Breaks #when which used to return the route definition object but now
returns self. Returning the route definition object is not very useful
so its likely that nobody ever used it.
The purpose of allowing the scope to be specified was to enable the $route service to work
together with ngInclude. However the functionality of creating scopes was in the recent past
moved from the $route service to the ngView directive, so currently there is no valid use case
for specifying the scope for ngInclude. In fact, allowing the scope to be defined can under
certain circumstances lead to memory leaks.
Breaks ngInclude does not have scope attribute anymore.
It turns out that listening only on "blur" event is not sufficient in many scenarios,
especially when you use form validation you always had to use ngModelnstant
e.g. if you want to disable a button based on valid/invalid form.
The feedback we got from our apps as well as external apps is that the
ngModelInstant should be the default.
In the future we might provide alternative ways of suppressing updates
on each key stroke, but it's not going to be the default behavior.
Apps already using the ngModelInstant can safely remove it from their
templates. Input fields without ngModelInstant directive will start propagating
the input changes into the model on each key stroke.
Previously if there was a white-space in fn: fn( ) {} we failed to infer no args.
This was originally reported by recht, but I decided to use a different fix.
Closes#829
