angular.js/src/ngResource, branch v1.2.1 docs(ngResource): removed buzz client example 2013-11-15T05:22:11+00:00 Jeff Cross 2013-11-15T05:13:39+00:00 40e34a924b629280eb572e957cc8a2cf4f88394c The Buzz Client example on the ngResource doc was causing parse errors. While the root cause is being investigated, the example has been removed, and should be replaced by a more relevant example anyhow. 
The Buzz Client example on the ngResource
doc was causing parse errors.

While the root cause is being investigated,
the example has been removed, and should be
replaced by a more relevant example anyhow.
docs(resource): fix grammatical issue 2013-11-14T13:12:36+00:00 mkolodny 2013-11-10T17:43:15+00:00 938b2e1217b1075aaeea3b54dc5693cffc077c83 'Case' should be the plural 'cases' since it is talking about multiple possible cases rather than a single case. For slightly more info, see the section 'When words like "none" are the subject' in this article: http://writing.wisc.edu/Handbook/SubjectVerb.html 
'Case' should be the plural 'cases' since it is talking about multiple possible cases rather
than a single case. For slightly more info, see the section 'When words like "none" are the
subject' in this article: http://writing.wisc.edu/Handbook/SubjectVerb.html
fix($resource): don't use $parse for @dotted.member 2013-11-12T00:17:34+00:00 Chirayu Krishnappa 2013-11-09T04:44:32+00:00 9577702e8d2519c1a60f5ac4058e63bd7b919815 params and paramDefaults support looking up the parameter value from the data object. The syntax for that is `@nested.property.name`. Currently, $resource uses $parse to do this. This is too liberal (you can use values like `@a=b` or `@a | filter` and have it work - which doesn't really make sense). It also puts up a dependency on $parse which is has restrictions to secure expressions used in templates. The value here, though a string, is specified in Javascript code and shouldn't have those restrictions. 
params and paramDefaults support looking up the parameter value from the
data object.  The syntax for that is `@nested.property.name`.
Currently, $resource uses $parse to do this.  This is too liberal
(you can use values like `@a=b` or `@a | filter` and have it work -
which doesn't really make sense).  It also puts up a dependency on
$parse which is has restrictions to secure expressions used in
templates.  The value here, though a string, is specified in Javascript
code and shouldn't have those restrictions.
docs($resource): fix typo 2013-10-27T21:51:53+00:00 Jarrett Harris 2013-10-27T05:46:32+00:00 c9a1df3ae92183fc5074b02389fff524c508b731 Closes #4670 
Closes #4670
chore(docs): fix jsHint errors with long lines 2013-10-23T21:44:37+00:00 Matias Niemelä 2013-10-23T21:44:37+00:00 269bc7e51f0ae4e4230308e43db934a9fff48756 






feat(docs): provide index pages for each angular module
2013-10-23T21:00:12+00:00

Matias Niemelä

2013-10-17T02:48:32+00:00

a7e12b7959212f2fa88fe17d5a045cc9d8b22922












style: make jshint happy
2013-10-22T22:32:41+00:00

Vojta Jina

2013-10-22T21:41:21+00:00

f2fab498303e00d199cb3d19a008670e214d5c10












chore(grunt): add jshint tasks
2013-10-22T22:32:40+00:00

Pete Bacon Darwin

2013-10-21T08:06:53+00:00

934a95d3ef3f72dfc37b0b564624cb4a1286d4f4












docs: correct broken links
2013-10-18T22:35:41+00:00

Vojta Jina

2013-10-18T02:25:08+00:00

14438058da39c3e523f420549074934ca5881b09

This also contains some whitespace corrections by my editor.





This also contains some whitespace corrections by my editor.







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