Routes like '/bar/foovalue/barvalue' matching '/bar/:foo/:bar'
now are well mapped in $routeParams to:
{bar:'barvalue', foo:'foovalue'}
Closes: #1501
Signed-off-by: Gonzalo Ruiz de Villa <gonzaloruizdevilla@gmail.com>
This is a minor edit to allow Plunks created by way of the docs.angularjs.org site to be appropriately tagged as `angularjs`.
Also, make these generated Plunks private by default.
So that when running the docs locally, eg. during e2e testing, we use the latest build version of angular, rather than the stable one from CDN.
This fixes e2e tests running with Testacular.
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.
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
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.
in jQuery 1.8.x the data() data structure is changed and events are
not accessible via data().events. Since all we need is to trigger
all event handlers, we can do so via triggerHandler() api instead of
mocking with the internal jQuery data structures.
This fix was originally proposed by PeteAppleton via PR #1512.
Closes#1512
we need triggerHandler() to become jQuery 1.8.x compatible.
this is not fully featured triggerHandler() implementation - it doesn't
bother creating new DOM events and passing them into the event handlers.
this is intentional, we don't need access to the native DOM event for our
own purposes and creating these event objects is really tricky.
Having a $resource defined as:
var R = $resource('/Path', {}, {
get: {method: 'GET', params: {objId: '1'}},
perform: {method: 'GET'}
});
was causing both actions to call the same URI (if called in this order):
R.get({}); // => /Path?objId=1
R.perform({}); // => /Path?objId=1
