ngModelOption's getterSetter does not work with Factory objects

[lightswitch05]

Overview of the Issue

When using ng-model-options="{ getterSetter: true }", the getter & setter methods do not run within the correct scope if defined in a factory. This causes this to be undefined within the getter & setter method - preventing anything from being set or retrieved. (TypeError: Cannot read property 'x' of undefined)

Motivation for or Use Case

While some getter & setter methods should be defined within the controller & scope - more complex objects should contain their own getter and setter methods defined within their factories for a better separation of concerns.

Angular Version

I've tried this with 1.3.0-rc.4 & 1.3.0-rc.3

Browsers and Operating System

This appears to be Angular.js specific and not a browser problem. However, I am using chrome 37.0.2062.124 m on windows 7 64bit.

Reproduce the Error

Here is a plunker that has getter & setter methods defined within a object from a factory that does not work: http://plnkr.co/edit/RmoegMYEgF9s7s50KQNj?p=preview

Here is another version that has the object defined within the controller (no factory) that works fine: http://plnkr.co/edit/4f8i384nsRwCoaQtPoxx?p=preview

[caitp]

This is kind of a dupe of #8552 (sort of).

So, the parser isn't the one invoking the function, and we have no way to get the context of the function :(

It would be good to make this work nicely everywhere though

[jtymes]

I was working with @lightswitch05 on this, and if it's not currently possible to get the context, maybe the docs should be updated to reflect that.

I volunteer @lightswitch05 to update the docs 😄

[lightswitch05]

@caitp I propose this as a solution:

getterSetter currently accepts a boolean if getter & setters are to be used. Thats fine - but how about allowing a context to be sent instead of true

thoughts?

[caitp]

I don't think that's particularly useful --- I would rather just change the parser so that it can return the context so that we can get it when we need it.

[caitp]

so I don't know how big of a problem this is, but I guess it couldn't hurt to fix it --- I just don't think it's a huge priority.

Maybe I'll write a patch for this on the weekend and see what people think

[lightswitch05]

I'm currently working around this by storing a reference to this and using non-prototypical getter & setter methods: http://plnkr.co/edit/nk35FTVECZiC8Uzj8aWY?p=preview

[NevilleS]

Something like this could work, although I'm not sure how many other things it would break...

In getterFn(path, options, fullExp) (angular.js:11601):

    var code = '';
    forEach(pathKeys, function(key, index) {
      ensureSafeMemberName(key, fullExp);
      code += 'var p = s;\n';
      code += 'if(s == null) return undefined;\n';
      if (index == 0) {
        // but if we are first then we check locals first, and if so read it first
        code += 's=((l&&l.hasOwnProperty("' + key + '"))?l:s)' + '.' + key + ';\n';
      } else {
        // we simply dereference 's' on any .dot notation
        code += 'p = s;\n'
        code += 's=s.' + key + ';\n'
      }
    });
    code += "if (typeof s === 'function' && p != null) return s.bind(p);\n"
    code += 'return s;';

[caitp]

would be a performance killer, not the right way to do this