I modified additional methods to support for stronger regular expressions. The current 'pattern' method in upstream does not support i, m, g modifiers while these are standard and commonly used. Also, the current method adds ^ $ metachars to its input RE if the the supplied RE has the type of string which is a wrong assumption. I improved the method to address these issues.
Add support for regexp modifiers(i, m, g) and ^$ metachars in string …
Thanks for the contribution. What does "Supports 3 regular expression modifiers: i, m, and g." mean? How does usage change with this patch?
Also, can you add or extend a unit test and fix the linting issues (see Travis build details, or run grunt)?
@koosha-- could you take another look at this? See my previous comment for details. Thanks.
The 'i' modifier lets the user match the pattern case-insensitively. /regex/i
The 'g' modifier lets the user match the pattern globally; i.e. more than once. /regex/g
and the 'm' modifier lets the user treat the input as multiline; that is the ^ and $ metachars are treated as the start and the end of the string regardless of the number of lines involved instead of the start and the end of a line.
I'm not sure if I would be able to add a unit test this soon.
Well, I think what I was looking for to "How does usage change with this patch?" was "You now provide regex literals as strings, e.g. pattern="/regex/i", since your update splits on the slashes. Is that correct?
Actually, yes. The patch enables the library to accept both strings and regex form (/regex/) as ways of representing regular expressions.
Will you merge this or not?
I still have a few issues with this: So far the pattern method pretty much matched the equivalent html5 pattern attribute. Your patch would change that. The html5 pattern attribute doesn't support specifying any flags (see also http://stackoverflow.com/questions/5524842/have-html5s-a-inputs-pattern-attribute-ignore-case ). Making a regex ignore case isn't so hard and I don't really understand how the m and g flags could be useful in this context.
I'd also need unit tests to land this.
I don't see the usecase for this. Since HTML5 doesn't support these either, I'm not inclined to deviate from that.