Expression doesnt work in ng-maxlength

[hyusetiawan]

here is the plink: http://plnkr.co/edit/FgmK1b?p=preview&s=tempoooo

checks the maxlength that is 5 using an expression, and it's not validated however, using {{expression}} it shows the value

[hyusetiawan]

the same thing happens to max validation, makes me wonder, does the validation directive accept expression? if not, how do we properly pass parameters to them?

[hkdobrev]

👍 I think I have found the problem here: https://github.com/angular/angular.js/blob/master/src/ng/directive/input.js#L494

The ngMaxlength, ngMinlength and perhaps other pseudo-directives used by the input directive do not evaluate the value of the attribute in the current scope, but just cast it to a integer.

Any input from the AngularJS core developers? @IgorMinar @btford

I think a int(scope.$eval(attr.ngMaxlength)) would do the job. What do you think?

[timneedham]

I would love to see this get fixed as well, the suggestion by @hkdobrev works great for me...

I'm new to these parts (loving AngularJS!), but it seems things may have stalled on this tiny issue? So as above, any input from the AngularJS core developers would be gratefully received! @IgorMinar @btford

[bowsersenior]

Just ran into this same problem and wasted a lot of time. It would be awesome if this could get fixed soon. Thanks!

[bowsersenior]

Oh, just noticed #1588 was closed a few months back due to failing tests. Anybody care to have a second look at that pull request to get the tests passing?

[blowsie]

+1 for fixing this! Is it planned to be fixed for version 1.2? or anytime soon?

[the-spyke]

Any progress on this?

[hkdobrev]

Hey, what's up with this one? 😄

https://github.com/blog/1721-the-ghost-of-issues-past

[anpsince83]

Another +1 for this. Seems like an essential feature for dynamic forms.

[blowsie]

Also should this really be tagged as a feature and not a bug?

[hkdobrev]

@blowsie It is not documented as if it's working, so it's not a bug.

[elranu]

👍 Another +1 for this. Seems like an essential feature for dynamic forms.

[MagRelo]

holla! +1

[Rodeoclash]

+1

[mlenser]

+1

[shanti2530]

+1

[rodyhaddad]

PRs welcome, plus fixing this should be backwards compatible 👍

[caitp]

there are PRs which implement this. (#1588 for instance)

[rodyhaddad]

@caitp the ones I saw are closed.
If you know of one that's still active and solves this, reference it so this issue gets closed when the PR gets merged?

[caitp]

they're closed, but they could be fixed up and checked in, it's not too difficult. The issue is that we can't seem to decide whether we actually want to support them or not, because once they're expressions, people will start asking for them to be $watched and etc. It gets ugly

[rodyhaddad]

We could watch them.
Constants will be unwatched anyway (e.g. 6), and bind-once can be used if you know the value never changes, and you want to optimize your application.

[caitp]

you know what's interesting @rodyhaddad, we don't actually consider an empty expression ("") as a constant, so we watch those forever if they get watched. we should probably fix that.

[hkdobrev]

Finally I've seen some kind of meaningful discussion going on for an issue from almost two years.

[rodyhaddad]

There is one issue with allowing for dynamic min/max-length.

Description: If there's a valid value in an input that respects the max-length constraint, and suddenly the max-length drops to 1, what would happen to the validation? Obviously the value is no longer valid, but do we have a way to re-run the validations and make the model value undefined?

[caitp]

Make sure matsko's patch has a test for that ;)

[caitp]

wait, it looks like it already got merged. is there a test for that? (this is about re-validating minlength/maxlength if their value changes --- ie when the observe listener is called. it is not about dealing with parsed expressions, but it could)

[gkalpak]

This seems to have been fixed in 1.3.0 http://plnkr.co/edit/5Im8QYngPc7lGw4oaYg6?p=preview&s=tempoooo
(It's still not working on 1.2.26.)

Should this be closed ?

[btford]

Should this be closed ?

We'll see.

@IgorMinar, do we want to cherry-pick these changes to 1.2.x?

[lgalfaso]

This is not going to be backported to 1.2, so can be closed