Validación

Hey sasa1007 !

Yea, there are a lot of ways to handle showing validation errors in Vue... because it's "sort of simple", but can involve a lot of repetition.

Should I create empty ErrorProduct for field Product

I'm not sure what you mean here - are these Vue components?

The easiest way to accomplish this might be to have a violations data on Vue that you set after the AJAX call fails. Each field would conditionally render the violation if it's there (you could of course, avoid some repetition by creating a re-usable component). I think the problem that you're talking about is the fact that the violations are an array ( [ ] ) instead of an object where each field name is a key in that object. That, indeed, makes it harder to handle in JavaScript (because you need to loop over the whole set to look for a specific field error).

Instead of changing this in Vue, I would use a helper function in JS to normalize however you want. For example:

const normalizedViolations = {};
response.data.violations.forEach((violation) => {
    normalizedViolations[violation.propertyPath] = violation.message;
});

Then you should be good. You could put this in a module so that you could re-use it:

// normalize-violations.js
export default function(violations) {
    // .. all the code above

    return normalizedViolations;
}

API Platform us following a "spec" with their response... and I think it's just easier to do the normalizing in JS than try to hijack API Platform.

Let me know if this helps :).

Cheers!

One more thing how to handle this kind of errors?

I got this error that is not in violations array

@context: "/api/contexts/Error"
@type: "hydra:Error"
hydra:description: "The type of the "region" attribute must be "string", "integer" given."
hydra:title: "An error occurred"

and this is my asserts in entity

/**
* @Assert\NotNull(message="Region ne sme da bude prazno polje")
* @Assert\NotBlank(message="Region ne moze ostati prazno polje")
* @Assert\Length(max="50", maxMessage="Licenca moze imate maksimum {{value}} karaktera")
* @ORM\Column(type="string", length=50, nullable=true)
* @Groups({"region:read", "region:write", "aplication:read"})
*/
private $region;

Hey sasa1007 !

If I remember correctly, this type of error doesn't come from the @Assert\ annotations - it comes from the type-hints that you have on your setter function. My guess is that your setRegion function has a string type-hint on the argument (and maybe you also have declare(strict_types=1) on your class... I can't remember if that's needed).

The point is: this error is because if your type-hint - API Platform is smart enough to read this and not allow an integer to be set on this field :).

Ideally, you would not get any of these types of errors (and instead would only get true validation errors) because these types of errors are impossible to "map" correctly to the field. But this is tricky due to how Symfony's validation system works: data first gets set onto your object and then it's validated. So, you could add a @Assert\Type("string") to your property, but you would need to remove the string type-hint from your argument... which (I admit) is kind of a bummer. Removing the declare(strict_types=1) might also work (I can't remember), but again - if you like using strict types, that's a serious trade-off.

So, sorry I can't offer an exact solution - but hopefully this helps!

Cheers!

For these reasons, wouldn't it be better to use API Resource with DTOs?

Hey julien_bonnier!

Yes, there are plenty of people who completely agree with what you said. If you create DTO's immediately, you get really nice, clean classes that model your API and can be "pure": they hold only API code and you can properly type your entity. I think the reason this isn't the *main* approach you see is that it requires more work. So, people tend to try to use their entities until it gets too complicated, and then they switch to a DTO. But going 100% DTO from the very beginning is a very robust approach.

Cheers!

Hey Sasa,

Thank you for sharing this solution with others!

Cheers!

Uh sorry maybe I wasn't clear enough, I edit question

Hey Sasa,

Ah, now I see it was a question, sorry :)

Cheers!

Thank you so much @weaverryan !
this part of code is what I looking for

const normalizedViolations = {};
response.data.violations.forEach((violation) => {
normalizedViolations[violation.propertyPath] = violation.message;
});

Hey Raul M.!

What does this constraint error look like exactly? And is your ApiResource class an entity?

If you're using NotBlank on the date field, then during a PUT operation, the date field (which was previously set when you created the item) will be loaded from the database and populated onto the object. Then, because it's missing from the JSON, it simply won't be changed. The end entity WILL then STILL have the date field populated. Validation is done on this final entity (where the date field is still populated), so it "should work". What's why I'm asking what that constraint error looks like, to make sure it IS coming from validation, and not potentially from something in the serializer. Also, what do your properties, groups and validation constraints look like?

Cheers!

Hi weaverryan ,

My ApiResource is an Entity and I finally solved this issue with the next configuration:

    /**
     * @var \DateTime
     *
     * @ORM\Column(name="fecha_inicio", type="date", nullable=false)
     * @Assert\NotBlank(groups={"postValidation"})
     * @Assert\Type("\DateTimeInterface")
     * @Groups({
     *      "comisiones:read",
     *      "comisiones:write"
     * })
     */
    private $fechaInicio;

Is this correct?

Because when I change the configuration to:

    /**
     * @var \DateTime
     *
     * @ORM\Column(name="fecha_inicio", type="date", nullable=false)
     * @Assert\NotBlank(groups={"postValidation"})
     * @Assert\DateTime
     * @Groups({
     *      "comisiones:read",
     *      "comisiones:write"
     * })
     */
    private $fechaInicio;

I get the next error:

{
  "@context": "/api/contexts/ConstraintViolationList",
  "@type": "ConstraintViolationList",
  "hydra:title": "An error occurred",
  "hydra:description": "fechaInicio: This value should be of type string.",
  "violations": [
    {
      "propertyPath": "fechaInicio",
      "message": "This value should be of type string.",
      "code": null
    }
  ]
}

Thanks in advance!

Raúl.

Hi again weaverryan !

Sorry but with the configuration I thought it worked I get also an error:

{
  "@context": "/api/contexts/Error",
  "@type": "hydra:Error",
  "hydra:title": "An error occurred",
  "hydra:description": "DateTime::__construct(): Failed to parse time string (hola) at position 0 (h): The timezone could not be found in the database",
  "trace": [
    {
      "namespace": "",
      "short_class": "",
      "class": "",
      "type": "",
      "function": "",
      "file": "/appdata/www/vendor/symfony/serializer/Exception/NotNormalizableValueException.php",
      "line": 31,
      "args": []
    },
   ...

How can I solve this validation?

Thank you for your help!

Raúl

Hey Raul M.!

Sorry for the slow reply!

First, the fact that using @Assert\DateTime doesn't work is actually because this constraint is meant to be applied to a string: it asserts that a string has a valid "date time" format - https://symfony.com/doc/current/reference/constraints/DateTime.html - its name IS a little misleading. So using Type is correct.

However, I rarely (never?) use @Assert\Type. The reason relates to your second question/error: the one about "Failed to parse time string". Instead of using validation constraints to enforce type, I typically use type-hints on my setters / properties. This is probably what you have done also - you probably have something like this:

public function setFechaInicio(?\DateTimeInterface $fecha)

And this is ALSO what I would have. With this setup, having the @Assert\Type on the property is redundant: it is not possible for a non-DateTimeInterface to EVER be set onto this property. And so, that validation will 100% never fail. BUT, what happens if your user sends a string like "hola" for the "fechaInicio" field in the API? That's the 2nd error you're getting. In this case, the data cannot be "denormalized": the serializer cannot figure out how to create a DateTimeInterface object from that string. And so, you get this "non normalizable exception". This is expected, and it results in a 400 error. I use the term "type validation" for this - https://symfonycasts.com/screencast/api-platform-extending/type-validation

Let me know if that makes sense. From what I'm seeing, the 2nd error is expected (there would not be a big stacktrace in production) and the Assert\Type is redundant, but not causing problems.

Cheers!

Hey @sridhar!

Sorry for the slow reply! Can you tell me more - I don’t quite understand what you mean by the “symfony error object”. Your business rules validation should be implemented via the validation system - using the @Assert annotations. And if you do this, those errors will be returned in the JSON. But... I have a feeling I’m not understanding you’re thinking fully, so let me know ;).

Cheers!

You have answered my question partially. I wanted to know if there was a way to inject the validation errors into symfony objects so that when the JSON is returned it contains the error message. It hadn't occured to me that we had @assert annotation in Symfony which does the job to an extent.

But then business application have several business rules, the simplest is to check if a candidate is old enough to apply for college or a job, in which case we need to derive it from the Date of Birth? Where should the code that computes the age be written? In the entity or the controller? Or do we have a service object?

Actual business scenarios can get a bit more complicated. There could be a series of vidations that the entity should meet before it can be actully written to the Database. Here is one usecase that come to mind. An individual should
1. Be over 18 years
2. Be a resident of the country
3. Have an Identity Proof
4. Have an address Proof......

Lets say the individual doesn't match any one of the above criteriaaI would like to trigger an error that is returned as a JSON. Wondering whats the right way to do it.

Hey Jason O.!

Hmm. The way it's parsed is determined by the Doctrine annotations parser, and actually, both of these syntaxes should be valid (I usually always include the (), but I believe their optional). What error do you get when you try @Assert\NotBlank()?

Cheers!

Hey @Chris

On production you still will see the error message but it's just the stack trace part that won't be shown (You don't really want your users to see that information)

Cheers!

Hey pcabreus

I'm sorry if that statement caused you some confusion. The automatic validation feature used to be enabled by default but Symfony people decided to change it. I believe it's enabled by default *only* on new projects

Cheers!

Hey MolloKhan and @Diego

Actually, this changed since the recording - and we'll need to add a note :). The feature does exist in Symfony 4.3, and can be enabled with some config. For about the first 2 weeks of June, if you started a new project, that configuration was present (via the recipe) and you *did* get auto validation. I was planning ahead for this. However, due to a few inflexibilities with the feature (which should be fixed for 4.4), we've disabled the feature in the browser. You can still enable it, but if you do nothing (as most people will), you will not get it.

We'll add a note to clarify that spot.

Cheers!

Hey John,

Ah, we're sorry about that! Yes, namespace was missed in the first code block, it's fixed now: https://symfonycasts.com/sc...

Thank you for reporting it!

Cheers!