Validation

[Korbeil]

Fixes #10 (one of the first tickets on this repository !)
Fixes #451

This PR will bring Validation specification thanks to Symfony Validator, this will allow Jane to validate data before normalization or denormalization.
If some validation error is found, Jane will trigger a ValidationException (found in the Runtime directory of your Jane generated files with your choosed namespace) containing a violation list.

---

Steps:

• Draft with enum field only
• Bring needed files with Validator folder
• Test a generated Normalizer
• Cover all Validation spec
  • Numeric
  • String
  • Array
  • Object
  • Format
  • Others
• Implement object Required fields
• Clean code
• Add an option to enable/disable validation (will be disabled by default for Client generation)

[er1z]

Last of the points — it'll be quite easy with validation groups. Others — I'd suggest to simply create something like tagged adapters loop with accept and fieldToConstraint methods. Simple and flexible. :)

[Korbeil]

Last of the points — it'll be quite easy with validation groups. Others — I'd suggest to simply create something like tagged adapters loop with accept and fieldToConstraint methods. Simple and flexible. :)

I don't see the point of using validation groups here ? Since we want to validate all the model everytime.

What this kind of complexity (tagged adapters, which won't really work like that since Jane is something that should work out of Symfony scope) will bring to Jane ? instead of this validator file that contains all the constraints ?

[Korbeil]

@joelwurtz gave me a quick review about how he thinks the validation should be done and gave me a really good example of how he see the generated validator:

namespace Jane\JsonSchema\Tests\Expected\Validator;

class ModelValidator implements Jane\JsonSchema\Tests\Expected\Validator\ValidatorInterface
{
    public function __construct(Symfony\Component\Validator\Validation $validator = null)
    {
        $this->validator = $validator ??  \Symfony\Component\Validator\Validation::createValidator();
    }
    public function validate($data): ConstraintViolationListInterface
    {
        return $this->validator->validate($data, self::getConstraint());
    }
    public function static getConstraint(): ConstraintInterface
    {
         // add some cache here ~
         return new \Symfony\Component\Validator\Constraints\Collection(array('enumString' => new \Symfony\Component\Validator\Constraints\Required(array(new \Symfony\Component\Validator\Constraints\Choice(array('choices' => array('foo', 'bar', 'baz'), 'message' => '"{{ value }}" is not part of the set of possible choices for this field: "{{ choices }}".')))), 'enumArrayString' => new \Symfony\Component\Validator\Constraints\Required(array(new \Symfony\Component\Validator\Constraints\Choice(array('choices' => array('foo', 'bar', 'baz'), 'message' => '"{{ value }}" is not part of the set of possible choices for this field: "{{ choices }}".')))), 'enumNoType' => new \Symfony\Component\Validator\Constraints\Required(array(new \Symfony\Component\Validator\Constraints\Choice(array('choices' => array('foo', 'bar', 'baz'), 'message' => '"{{ value }}" is not part of the set of possible choices for this field: "{{ choices }}".'))))));
    }
}

And was telling me to avoid using exception to get the violation list, he would more see the client returning violations directly when needed (this meant that I should move validation from Normalizers to the Client)

[Jrobles-Oniad]

Hi! What is the status of this issue?
I've considered other alternatives like using Opis JsonSchema before passing to the normalizer, but still prefer using Symfony validation that provides tighly integration.
Can you explain how is this planned to work? maybe generating the '@Assert::constraint` on property annotations will suffice?
Thanks!

[Korbeil]

Hi! What is the status of this issue?
I've considered other alternatives like using Opis JsonSchema before passing to the normalizer, but still prefer using Symfony validation that provides tighly integration.
Can you explain how is this planned to work? maybe generating the '@Assert::constraint` on property annotations will suffice?
Thanks!

Actually I did not plan to work on this topic anytime soon since I'm more focusing on v7 and AutoMapper features. Feel free to take over, I made a very detailed todo list in the PR description to what's missing but the big part that is missing is implementing each spec functionality one by one, the validation model is already working.
I'm also glad to take this back if you want to sponsor me, otherwise it will be planned later this year (mid/end of the year probably).

[Jrobles-Oniad]

Ok, thanks, I'll do some tests with the PR.

[Korbeil]

And it's done and open for reviews ! @Gounlaf maybe you could take a try there ?

[Gounlaf]

And it's done and open for reviews ! @Gounlaf maybe you could take a try there ?

With pleasure. Will do tonight or tomorrow 😉

[Gounlaf]

@Korbeil could you update options and split it in two?

As a user, I may want to validate my data before making call to the API I consume, but I don't want to validate that API is sending me "valid" data.
And vice versa; I could have have a validation process (on my own) before calling the API, so I don't need the built-in one, but I would like to validate APIs returns.

So it would be a double options; one for normalization, another one for de-normalization

[pyrech]

Just some wording suggestions in the documentation