angular.js/test/ng/directive, branch v1.2.0-rc.3 fix($compile): abort compilation when duplicate element transclusion 2013-10-12T00:12:24+00:00 Igor Minar 2013-10-11T04:35:54+00:00 63c5334c84b7269428c710226764d1f08a36e0d4 Issue an error and abort compilation when two directives that ask for transclusion are found on a single element. This configuration is not supported and we previously failed to issue the error because in the case of element transclusion the compilation is re-started and this caused the compilation context to be lost. The ngRepeat directive has been special-cased to bypass this warning because it knows how to handle this scenario internally. This is not an ideal solution to the problem of multiple transclusions per element, we are hoping to have this configuration supported by the compiler in the future. See #4357. Closes #3893 Closes #4217 Closes #3307 
Issue an error and abort compilation when two directives that ask for transclusion are found
on a single element. This configuration is not supported and we previously failed to issue
the error because in the case of element transclusion the compilation is re-started and this
caused the compilation context to be lost.

The ngRepeat directive has been special-cased to bypass this warning because it knows how to
handle this scenario internally.

This is not an ideal solution to the problem of multiple transclusions per element, we are
hoping to have this configuration supported by the compiler in the future. See #4357.

Closes #3893
Closes #4217
Closes #3307
feat(ngRepeat): use block separator comments 2013-10-09T22:19:10+00:00 jankuca 2013-09-23T18:24:42+00:00 9efa46ae640cde17487c341daa9a75c0bd79da02 Issue: multi-elements ng-repeat (ng-repeat-start, ng-repeat-end) can contain elements with a trancluding directive. This directive changes content of the row (template) and ng-repeat does not work correctly (when removing/moving rows), because ng-repeat works with the original template (elements). This changes ng-repeat behavior to traverse the DOM to find current elements everytime we are moving/removing rows (if the template has multiple elements). Closes #3104 
Issue: multi-elements ng-repeat (ng-repeat-start, ng-repeat-end) can contain elements with a trancluding directive. This directive changes content of the row (template) and ng-repeat does not work correctly (when removing/moving rows), because ng-repeat works with the original template (elements).

This changes ng-repeat behavior to traverse the DOM to find current elements everytime we are moving/removing rows (if the template has multiple elements).

Closes #3104
fix(input): `false` is no longer an empty value by default 2013-10-07T23:47:51+00:00 Pete Bacon Darwin 2013-09-25T11:49:55+00:00 b56b21a898b3c77589a48a290271f9dc181dafe8 `checkboxInputType` and `ngList` directives need to have special logic for whether they are empty or not. Previously this had been hard coded into their own directives or the `ngRequired` directive. This made it difficult to handle these special cases. This change factors out the question of whether an input is empty into a method `$isEmpty` on the `ngModelController`. The `ngRequired` directive now uses this method when testing for validity and directives, such as `checkbox` or `ngList` can override it to apply logic specific to their needs. Closes #3490, #3658, #2594 
`checkboxInputType` and `ngList` directives need to have special logic for whether
they are empty or not.  Previously this had been hard coded into their
own directives or the `ngRequired` directive.  This made it difficult to handle
these special cases.

This change factors out the question of whether an input is empty into a method
`$isEmpty` on the `ngModelController`.  The `ngRequired` directive now uses this
method when testing for validity and directives, such as `checkbox` or `ngList`
can override it to apply logic specific to their needs.

Closes #3490, #3658, #2594
fix(*): protect calls to hasOwnProperty in public API 2013-10-07T16:01:13+00:00 Peter Bacon Darwin 2013-10-05T09:49:09+00:00 7a586e5c19f3d1ecc3fefef084ce992072ee7f60 Objects received from outside AngularJS may have had their `hasOwnProperty` method overridden with something else. In cases where we can do this without incurring a performance penalty we call directly on Object.prototype.hasOwnProperty to ensure that we use the correct method. Also, we have some internal hash objects, where the keys for the map are provided from outside AngularJS. In such cases we either prevent `hasOwnProperty` from being used as a key or provide some other way of preventing our objects from having their `hasOwnProperty` overridden. BREAKING CHANGE: Inputs with name equal to "hasOwnProperty" are not allowed inside form or ngForm directives. Before, inputs whose name was "hasOwnProperty" were quietly ignored and not added to the scope. Now a badname exception is thrown. Using "hasOwnProperty" for an input name would be very unusual and bad practice. Either do not include such an input in a `form` or `ngForm` directive or change the name of the input. Closes #3331 
Objects received from outside AngularJS may have had their `hasOwnProperty`
method overridden with something else. In cases where we can do this without
incurring a performance penalty we call directly on Object.prototype.hasOwnProperty
to ensure that we use the correct method.

Also, we have some internal hash objects, where the keys for the map are provided
from outside AngularJS. In such cases we either prevent `hasOwnProperty` from
being used as a key or provide some other way of preventing our objects from
having their `hasOwnProperty` overridden.

BREAKING CHANGE: Inputs with name equal to "hasOwnProperty" are not allowed inside
form or ngForm directives.

Before, inputs whose name was "hasOwnProperty" were quietly ignored and not added
to the scope.  Now a badname exception is thrown.

Using "hasOwnProperty" for an input name would be very unusual and bad practice.
Either do not include such an input in a `form` or `ngForm` directive or change
the name of the input.

Closes #3331
 fix(ngRepeat): correctly track elements even when the collection is initially undefined 2013-09-25T16:42:01+00:00 jankuca 2013-09-24T20:51:28+00:00 31c56f540045b5270f5b8e235873da855caf3486 Previously if the collection model was set to undefined on the first digest, the repeater would get confused and not use the correct tracking function for associating model with dom elements in the repeater. Closes #4145 Closes #3964 
Previously if the collection model was set to undefined on the first digest,
the repeater would get confused and not use the correct tracking function
for associating model with dom elements in the repeater.

Closes #4145
Closes #3964
test(ng-non-bindable): test sibling bindings 2013-09-21T06:55:23+00:00 Chirayu Krishnappa 2013-09-21T01:03:29+00:00 e2751292dac5f7f4813bd2a3f0e8bbe3dcf4d6d9 Ref: https://github.com/angular/angular.dart/blob/master/test/directives/ng_non_bindable_spec.dart 
Ref: https://github.com/angular/angular.dart/blob/master/test/directives/ng_non_bindable_spec.dart
fix(ng-bind-html): watch string value instead of wrapper 2013-09-20T23:30:20+00:00 Chirayu Krishnappa 2013-09-20T23:30:20+00:00 e2068ad426075ac34c06c12e2fac5f594cc81969 Ref: https://github.com/angular/angular.js/pull/4045 I have this sinking feeling that support this use case sort of encourages binding to function that blindly trust some html. For now, I'm fixing the issue while I think about the use cases some more. In the case of a function that performs any non-trivial work before wrapping the value (e.g. the showdown filter in issue #3980, or the binding to a simply wrapper function in issue #3932 if it did anything meaty), this fix makes it "work" - but performance is going to suck - you should bind to some other thing on scope that watches the actual source and adjusts itself when that changes (e.g. the showdown filter.) For the case of the wrapper in #3932, if one isn't performing sanitization or some such thing - then you the developer has insight into why that value is safe in that particular context - and it should be available simply by name and not as a result of a function taking any arbitrary input to make auditing of security a little saner. Closes #3932, #3980 
Ref: https://github.com/angular/angular.js/pull/4045

I have this sinking feeling that support this use case sort of
encourages binding to function that blindly trust some html.  For now,
I'm fixing the issue while I think about the use cases some more.

In the case of a function that performs any non-trivial work before
wrapping the value (e.g. the showdown filter in issue #3980, or the
binding to a simply wrapper function in issue #3932 if it did anything
meaty), this fix makes it "work" - but performance is going to suck -
you should bind to some other thing on scope that watches the actual
source and adjusts itself when that changes (e.g. the showdown filter.)
For the case of the wrapper in #3932, if one isn't performing
sanitization or some such thing - then you the developer has insight
into why that value is safe in that particular context - and it should
be available simply by name and not as a result of a function taking any
arbitrary input to make auditing of security a little saner.

Closes #3932, #3980
fix(ngInclude): don't break attribute bindings on ngInclude-ed element 2013-09-20T21:11:12+00:00 Brian Ford 2013-09-20T18:04:37+00:00 5eb1fb6cb2c5a1c036e50ea791fd74ddf9016be0 BREAKING CHANGE: ngInclude's priority is now set to 1000 It's quite rare for anyone to depend on explicity directive priority, but if a custom directive that needs to run before ngInclude exists, it should have its priority checked and adjusted if needed. Closes #3793 
BREAKING CHANGE: ngInclude's priority is now set to 1000

It's quite rare for anyone to depend on explicity directive priority,
but if a custom directive that needs to run before ngInclude exists,
it should have its priority checked and adjusted if needed.

Closes #3793
fix(test): fixed toThrow usage 2013-09-17T23:13:25+00:00 Chirayu Krishnappa 2013-09-17T23:09:29+00:00 4b71bbc9886f6cf8e939d257c755bf7c4a94396e 






fix(ngOptions): ignore object properties which start with $
2013-09-13T11:48:19+00:00

Gowtam Lal

2013-09-13T11:41:51+00:00

aa3c54c73f7470999535294899a1c33cd193f455