Update StringConstraint.php

[ghost]

• Regex limitations removed because of starting and ending #
• add-et @preg_match to avoid regex notices and warnings

This will allow developers to create more complicated regex patterns for example #u as usage of Unicode ... only extra work in Schema is to supply pattern with starting and ending #

[bighappyface]

@xMolchy please review the Travis build. Several tests are now failing per these changes.

For the regex flexibility you are trying to achieve, is there another JSON Schema validator implementation out there that provides what you are looking for? I am wondering if the changes you are trying to contribute are aligned with the JSON Schema spec.

[ghost]

@bighappyface Did research and yes you are right it does not fallow any JSON Schema standard, so changes made can be ignored. Sorry for made mistakes (Working to much and rushing things ;) ).

Thing you can do is leave @preg_match so server will not pop out warnings and notices.

This i write for those that wishes to use UNICODE in their patterns (For example Arabic, Chinese ... )
characters check ..
In pattern "/u" can not be used and for that reason PCRE in PHP has hidden feature that allows you to check unicode characters.

If you specify (*UTF8) in regex then input-ed string will be encoded correctly. They say there is another option but has to be compiled on the server ....

THIS WILL CHECK CHARS, NUM AND DASH: *'#(UTF8)^[0-9\p{L}\p{Pd}\p{N}]+$#' and
will work same as '#^[0-9\p{L}\p{Pd}\p{N}]+$#u' which has unicode specification on the end

[bighappyface]

@xMolchy thanks for checking into the spec and spending more time on this.

I think leaving the @ error control operator out is the better course of action. Warnings and notices are valuable and I think that developers should be aware of problems when problems are present, regardless of severity.

In reviewing the code a bit further I believe the best course of action is to provide more flexibility in customizing constraint behavior. As I see it, modifying JsonSchema\Constraints\Factory to allow for arbitrary assignment of defined constraint handlers by type would allow you to extend/recreate StringConstraint with the changes in this PR and then indicate your version as the preferred implementation.

I have opened #221 to provide such behavior. Please review it and let me know if that will help you achieve the custom behavior you need without modifying the base constraint.

[ghost]

Looks good, will not break Schema standard and if someone wishes to extend constraints, add extra format support and make new constraint he can do that now ... great job!!!

First thing i tried was extend but failed (too many dependencies) ;) because sometime you have to go custom like with the car :D

[bighappyface]

@xMolchy thanks for the review. I am going to move forward with merging #221 so that you can use the updated code to assign your own custom string constraint.

[mirfilip]

@bighappyface Sorry to hijack the already closed post, but what is the "official" way to have a functionality like @xMolchy tried to provide? Build your own constraint class and set in the factory?

[bighappyface]

@mirfilip yes:

https://github.com/justinrainbow/json-schema/blob/05ce776136ba93d29eecd58d57fb6f95ea52307c/tests/JsonSchema/Tests/Constraints/FactoryTest.php