angular.js/src/ng, branch v1.1.1 fix($http): only set X-XSFR-TOKEN header for same-domain request 2012-11-26T22:58:59+00:00 Rado Kirov 2012-09-28T22:43:01+00:00 fce100a46c5681562253c3a856d67bbd35fbc2f2 This is needed to prevent CORS preflight checks. The XSFR token is quite useless for CORS requests anyway. BREAKING CHANGE: X-XSFR-TOKEN is no longer send for cross domain requests. This shouldn't affect any known production service. Closes #1096 
This is needed to prevent CORS preflight checks. The XSFR token
is quite useless for CORS requests anyway.

BREAKING CHANGE: X-XSFR-TOKEN is no longer send for cross domain
requests. This shouldn't affect any known production service.

Closes #1096
fix($http): remove 'X-Requested-With' from header defaults 2012-11-26T22:36:40+00:00 Rado Kirov 2012-10-12T19:41:05+00:00 3a75b1124d062f64093a90b26630938558909e8d X-Requested-With header is rarely used in practice and by using it all the time we are triggering preflight checks for crossdomain requests. We could try detecting if we are doing CORS requests or not, but it doesn't look like it's worth the trouble. BREAKING CHANGE: X-Requested-With header is not set by $http service any more. If anyone actually uses this header it's quite easy to add it back via: ``` myAppModule.config(['$httpProvider', function($httpProvider) { $httpProvider.defaults.headers.common["X-Requested-With"] = 'XMLHttpRequest'; }]); ``` Closes #1004 
X-Requested-With header is rarely used in practice and by using
it all the time we are triggering preflight checks for crossdomain
requests.

We could try detecting if we are doing CORS requests or not, but
it doesn't look like it's worth the trouble.

BREAKING CHANGE: X-Requested-With header is not set by $http service
any more. If anyone actually uses this header it's quite easy to add
it back via:

```
myAppModule.config(['$httpProvider', function($httpProvider) {
    $httpProvider.defaults.headers.common["X-Requested-With"] = 'XMLHttpRequest';
}]);
```

Closes #1004
fix($location): reset $location.$$replace with every watch call 2012-11-26T22:21:02+00:00 Rado Kirov 2012-09-22T01:57:22+00:00 a32bc40fd75ca46e3581ad7a6e3a24a31df6e266 Closes #1111 
Closes #1111
fix(ngClassOdd/ngClassEven): support shrinking/reordering in repeaters 2012-11-26T19:36:53+00:00 Igor Minar 2012-11-23T21:46:58+00:00 d859dcecea654d1d858cd756c6efb8435a453197 We need to watch $index in addition to cssClasses because only then we can correctly respond to shrinking or reordered repeaters. Closes #1076 
We need to watch $index in addition to cssClasses because only then
we can correctly respond to shrinking or reordered repeaters.

Closes #1076
fix(ngRepeat): support mostly-stable repeating for primitives 2012-11-26T19:36:53+00:00 Igor Minar 2012-11-23T21:43:30+00:00 1b17dfa693c36607ea86c7129a8612f7771c2f22 I'm reverting changes that were originally done to ngRepeat to fix #933, because these are now not necessary after the previous changes to keep ngModel always synced with the DOM. 
I'm reverting changes that were originally done to ngRepeat to fix #933,
because these are now not necessary after the previous changes to keep
ngModel always synced with the DOM.
fix(ngModel): sync ngModel state with scope state 2012-11-26T19:36:53+00:00 Igor Minar 2012-11-23T21:40:01+00:00 e6d9bea4f3b2eb28851298d3dc3a30d46062d58a In cases when we reuse elements in a repeater but associate them with a new scope (see #933 - repeating over array of primitives) it's possible for the internal ngModel state and the scope state to get out of sync. This change ensure that the two are always sync-ed up even in cases where we reassociate an element with a different (but similar) scope. In the case of repeating over array of primitives it's still possible to run into issue if we iterate over primitives and use form controls or similar widgets without ngModel - oh well, we'd likely need a special repeater for primitives to deal with this properly, even then there might be cornercases. Closes #933 
In cases when we reuse elements in a repeater but associate
them with a new scope (see #933 - repeating over array of
primitives) it's possible for the internal ngModel state and
the scope state to get out of sync. This change ensure that
the two are always sync-ed up even in cases where we
reassociate an element with a different (but similar) scope.

In the case of repeating over array of primitives it's still
possible to run into issue if we iterate over primitives and
use form controls or similar widgets without ngModel - oh well,
we'd likely need a special repeater for primitives to deal
with this properly, even then there might be cornercases.

Closes #933
fix(ngRepeat): attempt to simplify and improve existing fix for #933 2012-11-26T19:31:54+00:00 Igor Minar 2012-11-26T19:25:38+00:00 d644dcfa52cba0cee3c6fa8d03e1654cdb654e53 I'm keeping this in for future reference. The issue with this solution is that if we shift() the first item in the array, the whole repeater DOM will be rebuilt from scratch, we need to do better than that. 
I'm keeping this in for future reference. The issue with this solution
is that if we shift() the first item in the array, the whole repeater
DOM will be rebuilt from scratch, we need to do better than that.
feat(form): add ability to reset a form to pristine state 2012-11-26T15:44:34+00:00 Pawel Kozlowski 2012-07-07T17:02:04+00:00 733a97adf87bf8f7ec6be22b37c4676cf7b5fc2b Retting a form to pristine state will cause all of the nested form and form controls to be recursively reset as well. Closes #856 
Retting a form to pristine state will cause all of the nested
form and form controls to be recursively reset as well.

Closes #856
fix(Scope): allow removing a listener during event 2012-11-25T10:39:54+00:00 Vojta Jina 2012-09-25T08:09:26+00:00 e6966e05f508d1d2633b9ff327fea912b12555ac 






docs(api): add ngRequired to input/select/textarea directives
2012-11-25T00:18:10+00:00

Dean Sofer

2012-11-09T00:15:50+00:00

c8fd7fd0e2c77cc3d22382367ed5a1537383bee6

Closes #1202





Closes #1202