It looks like you unchecked the "Allow edits from maintainer" box. That is fine, but please note that if you have multiple commits, you'll need to squash your commits into one before this can be merged. Or, you can check the "Allow edits from maintainers" box and the maintainer can squash for you.

Cheers!

Carsonbot

I do like the feature, but thinking about an extreme example of going all-in on attributes, I wonder were it goes.

Small simple example of building an app where we store informations about Events sent by users with our own schema, and we also receive informations from APIs with their own structure (you see where this is going). So we need the usual ORM attributes, some Validation, Object-Mapper, and these Form attributes. The entity becomes quite heavy on attributes.

useApp\Dto\EventasEventDTO;useApp\Repository\EventRepository;useDoctrine\DBAL\Types\Types;useDoctrine\ORM\MappingasORM;useSymfony\Component\Form\Attribute\AsFormType;useSymfony\Component\Form\Attribute\Type;useSymfony\Component\Form\Extension\Core\TypeasFormType;useSymfony\Component\ObjectMapper\Attribute\Map;useSymfony\Component\Validator\ConstraintsasAssert;#[AsFormType]#[Map(target: EventDTO::class)]#[ORM\Entity(repositoryClass: EventRepository::class)]class Event{    #[ORM\Id]    #[ORM\GeneratedValue]    #[ORM\Column]private ?int$id =null;    #[Map(target:'eventName')]    #[Assert\Length(min:15)]    #[Assert\NotBlank()]    #[ORM\Column(length:255)]    #[Type]private ?string$name =null;    #[Map(target:'synopsis')]    #[Assert\NotBlank()]    #[ORM\Column(type: Types::TEXT)]    #[Type(FormType\TextareaType::class)]private ?string$description =null;// ...

As you can see, the business need is small, there's not much in terms of validation or mapping, and I've included only few properties.

I don't know if that's a problem honestly, it's not that unreadable to me, by I do think the question should be raised.

That being said, once again, this is a really nice and neat feature, great job!

I do like the feature, but thinking about an extreme example of going all-in on attributes, I wonder were it goes.

Small simple example of building an app where we store informations about Events sent by users with our own schema, and we also receive informations from APIs with their own structure (you see where this is going). So we need the usual ORM attributes, some Validation, Object-Mapper, and these Form attributes. The entity becomes quite heavy on attributes.

use App\Dto\Event as EventDTO;use App\Repository\EventRepository;use Doctrine\DBAL\Types\Types;use Doctrine\ORM\Mapping as ORM;use Symfony\Component\Form\Attribute\AsFormType;use Symfony\Component\Form\Attribute\Type;use Symfony\Component\Form\Extension\Core\Type as FormType;use Symfony\Component\ObjectMapper\Attribute\Map;use Symfony\Component\Validator\Constraints as Assert;#[AsFormType]#[Map(target: EventDTO::class)]#[ORM\Entity(repositoryClass: EventRepository::class)]class Event{    #[ORM\Id]    #[ORM\GeneratedValue]    #[ORM\Column]    private ?int $id = null;    #[Map(target: 'eventName')]    #[Assert\Length(min: 15)]    #[Assert\NotBlank()]    #[ORM\Column(length: 255)]    #[Type]    private ?string $name = null;    #[Map(target: 'synopsis')]    #[Assert\NotBlank()]    #[ORM\Column(type: Types::TEXT)]    #[Type(FormType\TextareaType::class)]    private ?string $description = null;    // ...

As you can see, the business need is small, there's not much in terms of validation or mapping, and I've included only few properties.

I don't know if that's a problem honestly, it's not that unreadable to me, by I do think the question should be raised.

That being said, once again, this is a really nice and neat feature, great job!

I think in your usecase if you map object to a dto then the form should probably be on said dto. WDYT ?

I think in your usecase if you map object to a dto then the form should probably be on said dto. WDYT ?

I know you love teasing me 😉 . Just to keep you happy:

1. It's a fictitious example made just for testing
2. In this case the DTO is intended to receive data from an API and allow mapping to the entity, when the entity is the base for the frontend form.

I don't pretend this usecase is universale though. Once again, it's designed to create a fake extreme example, to show what it could lead. It's more of a "let's pretend there's a need like that".

And then again, I don't say I'm definitely against this, I love the feature. But I also like to raise questions ;)

This look like a fantastic addition for simple forms, but honestly I'm not 100% sure for mid-level and complex forms.

PHP attributes are excellent for declaratively adding metadata, but there are limitations and cases where attributes are not the best fit. For instance, dynamic field definition, custom business logic, injecting services, or conditional configuration. In those cases, the traditional FormType classes may still be preferable (as they are services by definition).

I don’t think we should replicate all form type capabilities with attributes (because the scope and dynamic limitations), but they can certainly be useful for building simple forms quickly, and then easily switch to FormType classes when things get more complex.

@yceruto : Yes this is a totally valid point. I don't think attributes are meant to replace Forms. But should try to cover most common cases without the need to refactor it to a dedicated class. Might be worth adding a warning to the documentation of this feature the list of known limitations.

$form =$formFactory->create(UserDTO::class,$user);

It looks strange from the design PoV passing the DTO class as form type. I’m wondering if, instead of passing the data class, we can leave the form type param asnull and let the type be guessed from the data (if AsFormType)?

$form =$formFactory->create(null,$user);// the form type will be guessed and defined from the DTO

Maybe the same guesser mechanism could help with this? It'd be aligned with the null form type concept.

@Tiriel Yes it can be used directly on entities, but even with your example, to make it more readable, a dedicated DTO for the form can still be done 😉

@yceruto I think its a good start to keep it simple yes. We just need to set the limit to which capabilities we want to replicate. I also thought of a command that can "convert" an attribute form to a traditionalFormType, something likemake:form:from-metadata. WDYT?

And Im totally agree to something like :

$form =$formFactory->create(null,$user);// or even?$form =$formFactory->create($user);

@Tiriel Yes it can be used directly on entities, but even with your example, to make it more readable, a dedicated DTO for the form can still be done 😉

In that case, what would be the benefit of using a new dedicated DTO+ attribute over a regular FormType class?

I think its a good start to keep it simple yes. We just need to set the limit to which capabilities we want to replicate.

There are implicit limitations with options and Closures, which may be mitigated in PHP 8.5, but still, adding large blocks of logic in attributes feels a bit messy to me.

I think advanced features like data mappers, form events, and model/view transformers carry special complexity and responsibility tied to the form type itself, but I’m open to making them configurable using attributes, as long as we can also implement them outside the DTO.

I also thought of a command that can "convert" an attribute form to a traditional FormType, something like make:form:from-metadata. WDYT?

Yes, but what about just creating a command that generate the form type from a DTO 😅?
It's already possible from an Entity classhttps://github.com/symfony/maker-bundle/blob/1.x/src/Maker/MakeForm.php

And Im totally agree to something like :
$form = $formFactory->create(null, $user);
// or even?
$form = $formFactory->create($user);

even$form = $formFactory->create(data: $user) is fine currently

And Im totally agree to something like :
$form = $formFactory->create(null, $user);
// or even?
$form = $formFactory->create($user);

even$form = $formFactory->create(data: $user) is fine currently

Symfony does not guarantee named arguments on methods at the moment. So maybe better not show this on documentation / example ?

@Tiriel Still one class less, less code:

• Traditional (with DTO): Entity + DTO + FormType
• Attributes (with DTO) : Entity + DTO

@yceruto

which may be mitigated in PHP 8.5

Yes, using the closure inside attributes in 8.5 can remove some limitations.

I think advanced features like data mappers, form events, and model/view transformers carry special complexity and responsibility tied to the form type itself, but I’m open to making them configurable using attributes, as long as we can also implement them outside the DTO.

Agreed

Yes, but what about just creating a command that generate the form type from a DTO 😅?

Can still be done, those 2 features are not mutually exclusive 😄

@Tiriel Still one class less, less code:

• Traditional (with DTO): Entity + DTO + FormType
• Attributes (with DTO) : Entity + DTO

I don't think we're talking about the same thing and we're going deep into things not strictly related to this feature. I don't see the point of the DTO in the first traditional case. And so, the number of classes is the same.

But that's beside the point. I'm not against you or the feature, I'm just saying that there are use cases where this could lead to bloated entities. And I'm not sure that advising user to put the attributes on another unnecessary class is the best solution.

But then again I seem to be the only one fearing that so maybe it's not that much of a concern.

Still one class less, less code:

Traditional (with DTO): Entity + DTO + FormType
Attributes (with DTO) : Entity + DTO

In terms of number of classes, yes. But to be fair, it’s not significantly less code. We’re going to inline the form type definition within the DTO class using attributes instead, so you’ll have to write extra code for that purpose.

The comparison should be in terms of coding:Attributes (with DTO): Entity + DTO + Attributes. It reduces the boilerplate of defining form fields and having an extra class. It makes things simpler for simple forms. Yes!

I loved the auto form example, but I’m afraid it would work only as a sample. In practice, you’ll need to define at least the field type to match the property’s purpose.

I loved the auto form example, but I’m afraid it would work only as a sample. In practice, you’ll need to define at least the field type to match the property’s purpose.

I'm not sure to be honest.. or, to be more precise, it happens in simple cases, and at least for these it's a real DX improvement.

The entity becomes quite heavy on attributes.

A fair point—and one we fully anticipated! 🙂

That said, I don’t believe it’s our role to prevent users from adding attributes here… but neither should we encourage using entities directly in forms. At the end of the day, everyone will adopt the approach that fits their project and philosophy best.

Ultimately, this is one of the original goals of this work: to provide anunopinionated way to define forms directly on the data class... whatever class that may be.