Form Model Classes (DTOs)

Damn, please delete this comment and my comment above...I just failed with copy & paste, sorry!

Haha, do not worry man :)

This is what I just came up with:

DTO:

`use GenericSetterTrait;

/**

• @Assert\NotBlank
  */
  public string $title;

public function setTitle(?string $title): void
{

$this->set('title', $title);

}

/**

• @Assert\NotNull
  */
  public Foo $foo;

public function setFoo(?Foo $foo): void
{

$this->set('foo', $foo);

}`

Trait:

`trait GenericSetterTrait
{

private function set(string $propertyName, $value): void
{
    if ($value === null) {
        unset($this->{$propertyName});
    } else {
        $this->{$propertyName} = $value;
    }
}

}`

Seems to work. What do you think? Any objections?

if you're using public properties, then you don't need setter methods. About the set(string $propertyName, $value) method. I particularly don't like that kind of magic methods but if you have a valid use-case where it will save you a lot of time, then go ahead.

This setter method prevents the "Typed property App\Form\Dto\ProductDto::$title must be string, null used" error. That's the reason I added it.

In that case, you can make the "title" property private, right?

Hey Roland W.

Do you get that error by submitting the form with an empty title? If that's the case, then, that's the right behavior because you updated the ProductDto title's from foo to null and it's not allowed to be null. Try setting a different value for the title and see if that works (it should).

Cheers!

Yes, that is exactly my problem. So type properties must be used with the ? Operator in these DTOs when data is passed to the form, right?

Isn’t there another way - I would really like to use typed properties without the ? operator.

I'm afraid that's a downside of using Symfony forms. Using a DTO helps at it so your entities can *stop* allowing nulls but the DTO class still have to.

..

Yo Mike P.!

I just saw that feature! It's super cool - I *love* it. But I guess you would need to create one constraint class per property that has constraints... and then apply that on both the entity and DTO properties. So, it *would* cut down on some duplication (if a property has 3 constraints, you wouldn't need to repeat that on each constraint), but I guess you would still need to have each constraint on both entity & DTO properties. So... it *helps*, but doesn't eliminate it entirely, I think. Or do you disagree? I'm asking because... I hope I'm not seeing something and would love to be wrong :).

Cheers!

I agree 100% 👍
Could you please take a look at this case:
https://symfonycasts.com/sc...

I would love to hear feedback from you to clear my mind! :)

Cey Mike P.

DTO's are good when you have a form that is conformed of many different entities
Embedded forms are good when you want to add or remove items of the form. For example, you have a Users and Articles, a User may have many Articles, so in your form you may want to manage the user information and the list of his articles (It may not be the best example but I hope it helps you clarifying things a little bit)

Cheers!

And if you want a combination of both worlds, we need to use both?

By example:
I haven an Recipe Entity, with a ManyToMany to Ingredients and Categories.
The "new recipe" page does a have a new "ingredient" field for each ingredient. (Which means each ingredient has its OWN text field)

So in this example, we have different entities (recipe & ingredient & category) and items (ingredients) can be added or removed.
So in this case I should use both, DTO and embedded forms?

Could you clear my mind please :)
Thanks in advance!

Hey Mike P.!

It sounds like you actually have a fairly simple (I mean "fairly", because this situation is never that simple) example of an entity (Recipe) which has an embedded collection of other entities (Recipe). As far as I can tell, the Categories relationship is not important for this form. And also, there are no extra/weird fields.

So, this seems like a fairly simple CollectionType situation... which still makes it tough. If you used entities, you would use the CollectionType on a RecipeFormType over to an IngredientFormType. The IngredientFormType would probably only have one field - a text field. That could definitely work - you would need cascade={"persist"} on the ingredients relationship... but it should work. Still, the JavaScrip with a CollectionType is a pain.

So... I would probably instead do this:

1) Create a RecipeFormType that is bound to the Recipe entity (because, as far as I know, there aren't many weird fields - other than the ingredients - that would necessitate using a DTO).

2) For the "ingredients" field on that form, make it 'mapped' => false and a CollectionType using TextType - I think the code is:

$builder->add('ingredients', CollectionType::class, [
    'entry_type' => TextType::class
]);

3) In the template, you would still be dealing with a CollectionType, but hopefully it will be a bit simpler because it will just be a collection of input boxes. You can use the normal Symfony way of doing the "add new" thing, or (honestly), you could render the widget {{ form_widget('ingredients'), which I think will render nothing on this "new" form - then just write your own JavaScript to do everything. As long as you end up with a bunch of input fields with the correct name attribute, the form won't know the difference.

4) On submit, use $form->get('ingredients')->getData() to get the array of strings. Turn these into Ingredient objects and link them.

So... it's all about trying to reduce complexity - and, for me, complexity is all about the CollectionType. Let me know what you end up doing and how it goes!

Cheers!

hey Larry Lu

For such cases there is Symfony\Component\Validator\Constraints\All constraint, nit sure that it will work with annotations, but if constraints defined programmatically it should work in combination with Collection constraint
It will be something like this:

$constraint = new Assert\All(['constraints' => [
    new Assert\Collection([
        'name' => new Assert\NotBlank(),
        'address' => new Assert\NotBlank()
    ])
]);

if I didn't missed something =)

Cheers! Hope this will help!

Thanks it works. I followed that $constraint with the validator check and it's able to check my $data array.

`$errors = $validator->validate($data, $constraint);

if (count($errors) > 0 ) {

$errorsString = (string) $errors;
return new JsonResponse(
    [
        'validation failed' => $errorsString
    ]);

}`

So does this mean that I don't have to use the DTO model class anymore? And that check for validator error is the replacement for the if ($form->isSubmitted() && $form->isValid()) block if I were working with form?

You can add this $constraint to your form class, and continue using form, I think controllers are more readable when you using forms =)

Cheers!

Hey Rita M., probably a DataTransformer is what you need: https://symfony.com/doc/cur...
but if it doesn't fit your needs, then probably you may have to fetch entity objects and then code a function for transforming them into a DTO list.

Cheers!