Support promises in ui-validate to allow remote validation

[ccollie]

Subject says it all.

[petebacondarwin]

Can you give a concrete example of how you see this working?

On 4 November 2012 21:09, ccollie notifications@github.com wrote:

Subject says it all.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/257.

[ProLoser]

I think he wants a call back to be passed so that validation can be
asynchronous. I was actually thinking about this myself before but I am not
entirely sure this is possible because AngularJS validation is synchronous
so by that time you won't be in the same phase of validation.

I suppose you could return false until the Ajax completes and then set
valid to true. But you could also just write validation the native way too.
On Nov 4, 2012 1:10 PM, "Pete Bacon Darwin" notifications@github.com
wrote:

Can you give a concrete example of how you see this working?

On 4 November 2012 21:09, ccollie notifications@github.com wrote:

Subject says it all.

—
Reply to this email directly or view it on GitHub<
https://github.com/angular-ui/angular-ui/issues/257>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-10055472.

[pkozlowski-opensource]

@petebacondarwin @ProLoser Yeh, I was toying with the idea as well (I think I've even sent a PR or sth on the mailing list, don't remember really...).

I guess the use case is validation hitting the server.

I think it could be possible to support promises if we accept the fact that we would initially set the field as invalid and then set the real validation result only when a promise is resolved. The real trouble is the sync nature of AngularJS validators...

[ProLoser]

Yes, in which case this just might not be in scope which is okay too. I
think doing invalid first and valid second might very well be a decent
solution. If people want something more robust nothing stops them from
doing native validation.

We could just provide some $callback that people could execute to change
the valid state.
On Nov 4, 2012 1:22 PM, "Pawel Kozlowski" notifications@github.com wrote:

@petebacondarwin https://github.com/petebacondarwin @ProLoserhttps://github.com/ProLoserYeh, I was toying with the idea as well (I think I've even sent a PR or sth
on the mailing list, don't remember really...).

I guess the use case is validation hitting the server.

I think it could be possible to support promises if we accept the fact
that we would initially set the field as invalid and then set the real
validation result only when a promise is resolved. The real trouble is the
sync nature of AngularJS validators...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-10055599.

[petebacondarwin]

You can't set the field to invalid as you get a horrible wobble of unwanted
error message while you wait for the server to decide that the thing you
entered is perfectly valid. Not nice from a user experience point of view.

What you need to do is just pass (i.e. return the value and don't call
$setValidity at all) until the async returns (possibly setting up a spinner
animation to let the user know that you are waiting for a response) you can
then call $setValidity once the server returns.

But anyway, how is this to be handled by the validate directive? Is it
that we check to see if the the validation function returns a promise and
act accordingly?

Pete

On 4 November 2012 21:30, Dean Sofer notifications@github.com wrote:

Yes, in which case this just might not be in scope which is okay too. I
think doing invalid first and valid second might very well be a decent
solution. If people want something more robust nothing stops them from
doing native validation.

We could just provide some $callback that people could execute to change
the valid state.
On Nov 4, 2012 1:22 PM, "Pawel Kozlowski" notifications@github.com
wrote:

@petebacondarwin https://github.com/petebacondarwin @ProLoser<
https://github.com/ProLoser>Yeh, I was toying with the idea as well (I
think I've even sent a PR or sth
on the mailing list, don't remember really...).

I guess the use case is validation hitting the server.

I think it could be possible to support promises if we accept the fact
that we would initially set the field as invalid and then set the real
validation result only when a promise is resolved. The real trouble is
the
sync nature of AngularJS validators...

—
Reply to this email directly or view it on GitHub<
https://github.com/angular-ui/angular-ui/issues/257#issuecomment-10055599>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-10055704.

[ProLoser]

Ya that sounds good to me.

Of course @ccollie could help us too ;)

On Sun, Nov 4, 2012 at 1:32 PM, Pete Bacon Darwin
notifications@github.comwrote:

You can't set the field to invalid as you get a horrible wobble of
unwanted
error message while you wait for the server to decide that the thing you
entered is perfectly valid. Not nice from a user experience point of view.

What you need to do is just pass (i.e. return the value and don't call
$setValidity at all) until the async returns (possibly setting up a
spinner
animation to let the user know that you are waiting for a response) you
can
then call $setValidity once the server returns.

But anyway, how is this to be handled by the validate directive? Is it
that we check to see if the the validation function returns a promise and
act accordingly?

Pete

On 4 November 2012 21:30, Dean Sofer notifications@github.com wrote:

Yes, in which case this just might not be in scope which is okay too. I
think doing invalid first and valid second might very well be a decent
solution. If people want something more robust nothing stops them from
doing native validation.

We could just provide some $callback that people could execute to change
the valid state.
On Nov 4, 2012 1:22 PM, "Pawel Kozlowski" notifications@github.com
wrote:

@petebacondarwin https://github.com/petebacondarwin @ProLoser<
https://github.com/ProLoser>Yeh, I was toying with the idea as well (I
think I've even sent a PR or sth
on the mailing list, don't remember really...).

I guess the use case is validation hitting the server.

I think it could be possible to support promises if we accept the fact
that we would initially set the field as invalid and then set the real
validation result only when a promise is resolved. The real trouble is
the
sync nature of AngularJS validators...

—
Reply to this email directly or view it on GitHub<

https://github.com/angular-ui/angular-ui/issues/257#issuecomment-10055599>.

—
Reply to this email directly or view it on GitHub<
https://github.com/angular-ui/angular-ui/issues/257#issuecomment-10055704>.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-10055722.

Dean J Sofer
DeanSofer@gmail.com

BS Computer Information Systems
California State Polytechnic University, Pomona
Telephone: 714-900-2254
Website: www.DeanSofer.com
Github: github.com/ProLoser

[pkozlowski-opensource]

@petebacondarwin we don't need to explicitly check for promises, we can simply wrap whatever comes out of a function in $q.when and register .then callback on it. I believe that this is what is done on routes matching (and possibly in other places in AngularJS as well).

Now, the only thing that we need to check if things will work correctly if we don't return any value from a validator function. I thought that this is what AngularJS is using to set model / view value. But sure, we could always set it "by hand".

[ProLoser]

It doesn't hurt to have a check or simply undefined, etc, at the very least.

On Sun, Nov 4, 2012 at 1:41 PM, Pawel Kozlowski notifications@github.comwrote:

@petebacondarwin https://github.com/petebacondarwin we don't need to
explicitly check for promises, we can simply wrap whatever comes out of a
function in $q.when and register .then callback on it. I believe that
this is what is done on routes matching (and possibly in other places in
AngularJS as well).

Now, the only thing that we need to check if things will work correctly if
we don't return any value from a validator function. I thought that this is
what AngularJS is using to set model / view value. But sure, we could
always set it "by hand".

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-10055817.

Dean J Sofer
DeanSofer@gmail.com

BS Computer Information Systems
California State Polytechnic University, Pomona
Telephone: 714-900-2254
Website: www.DeanSofer.com
Github: github.com/ProLoser

[petebacondarwin]

Nice one with the $q.when!

In a $parser/$formatter have to return the value that is passed in.
Otherwise you are telling ngModelController that the model value should be
wiped out.

For example, in ngModelController#$setViewValue you have these lines of
code:

forEach(this.$parsers, function(fn) {
      value = fn(value);
    });

And then later,

this.$modelValue = value;

Pete

On 4 November 2012 21:44, Dean Sofer notifications@github.com wrote:

It doesn't hurt to have a check or simply undefined, etc, at the very
least.

On Sun, Nov 4, 2012 at 1:41 PM, Pawel Kozlowski notifications@github.comwrote:

@petebacondarwin https://github.com/petebacondarwin we don't need to
explicitly check for promises, we can simply wrap whatever comes out of
a
function in $q.when and register .then callback on it. I believe that
this is what is done on routes matching (and possibly in other places in
AngularJS as well).

Now, the only thing that we need to check if things will work correctly
if
we don't return any value from a validator function. I thought that this
is
what AngularJS is using to set model / view value. But sure, we could
always set it "by hand".

—
Reply to this email directly or view it on GitHub<
https://github.com/angular-ui/angular-ui/issues/257#issuecomment-10055817>.

Dean J Sofer
DeanSofer@gmail.com

BS Computer Information Systems
California State Polytechnic University, Pomona
Telephone: 714-900-2254
Website: www.DeanSofer.com
Github: github.com/ProLoser

—

Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-10055846.

[ProLoser]

I want to add this functionality. I'm slating it for v0.4.1, anyone is free to open a PR for it if it hasn't been already done by then.

[andreas-gruenbacher]

This feature is unfortunately not covered by the tests in ui-utils. (I was looking for that for for an up to date example of how to use this.)

[ProLoser]

I believe that it should work but you are probably right about the missing
test
On Oct 5, 2013 9:17 PM, "Andreas Gruenbacher" notifications@github.com
wrote:

This feature is unfortunately not covered by the tests in ui-utils. (I was
looking for that for for an up to date example of how to use this.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/257#issuecomment-25762076
.

[andreas-gruenbacher]

Thanks. As it turns out, this is broken with angular 1.2.0-rc2 (but works with 1.1.5). The problem is here (validate.js):

var expression = scope.$eval(exprssn, { '$value' : valueToValidate });

In my test case, exprssn calls a function in scope which returns a promise. With angular 1.1.5, the $eval returns the promise, but in angular 1.2.0-rc2, the very same code returns undefined instead.

Any ideas?

[andreas-gruenbacher]

Ah, in the angular repository, src/ng/parse.js:functionCall(), we have this:

  // Check for promise
  if (v && v.then) {
    var p = v;
    if (!('$$v' in v)) {
      p.$$v = undefined;
      p.then(function(val) { p.$$v = val; });
    }
    v = v.$$v;
  }

[ghost]

Yeah promise based validation seems to be broken, can someone confirm this?

[ProLoser]

@exigoenergy wrong repo