Skip to content

Custom constraints #198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 8 commits into from
Closed

Conversation

AubreyHewes
Copy link

Allows adding custom constraints via

$validator->addConstraint('name', \Callable|className|instance)

Background
I ran in to the problem of custom constraints and via pr #143 by @Maks3w (the factory) the possiblity was available to easily accomplish adding custom constraints.. (this is moved from a @Maks3w fork)

Implementation
This allows applying custom constraints, by name, as either a callable/className/instance.
I am not saying this is how it should be --- all input welcome.

i.e. schema

{ 'myCustomCheck': value }

Can be constrained via $validator->addConstraint('myCustomCheck', $constraint)

Add a callable constraint

$validator->addConstraint('test', \Callable);
  • Inherits current/default ctr params (mode, uriRetriever, factory) - what the factory does internally
  • The callable is the ConstraintInterface->check signature function ($value, $schema = null, $path = null, $i = null)

Add by Constraint class-name

$validator->addConstraint('test', 'FQCN');
  • Inherits current/default ctr params (mode, uriRetriever, factory) - what the factory does internally
  • FQCN must be of type JsonSchema\Constraints\ConstraintInterface

Add by Constraint instance

$validator->addConstraint('test', new MyCustomConstraint(...));
  • Possibly requires adding the correct ctr params (mode, uriRetriever, factory et al) - what the factory does internally; If not the mode will be the default and the uriRetriever/factory will be another instance (if this is a problem remains to be seen)
  • MyCustomConstraint must be of type JsonSchema\Constraints\ConstraintInterface

@bighappyface
Copy link
Collaborator

Please explain the need for custom constraints outside of the JSON Schema spec?

Wouldn't a custom constraint in a given schema only work for this validator and not others?

@AubreyHewes
Copy link
Author

The official spec is too concrete for normal usage; the change is mostly based on (fe) https://github.com/acornejo/jjv#custom-checks

  • support same schema in fe/be

Also slightly based on the "format" spec:

For optimal schema usage you should be able to define own constraints, outside of the spec;

{ 'myCustomCheck': expectation }

And be able to test your constraint ... this allows this. Even if it is not spec.. it just opens up the possibilities.

Yes you need to create a validator for the required schema validation... This may be different than a previous global validator..(if this is what you meant)? So also enhances creating a new validator specific to the requirement.

@AubreyHewes
Copy link
Author

The PR is slightly superfluous as you can add your own factory (with own custom constraints) per validator instance.

@bighappyface
Copy link
Collaborator

@AubreyHewes thanks for your patience and insight. Would you please rebase and squash this PR down to a single commit?

@AubreyHewes
Copy link
Author

@bighappyface I am leaning towards this being superfluous. As via the factory you can do your own stuff anyway.. Also directly supporting custom attributes/stuff does not help the json spec.
Own business/domain spec should not be part of a spec validation. I.e. apply jsonschema and then apply own business/domain spec? Will close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants