Handling Constructor-Initialized Fields in make:form to Prevent Unwanted User Overrides

[halfpass25]

Description

Disclaimer: I'm new to contributing on GitHub, so I'm learning as I go—any guidance is much appreciated! I tried searching your repo for the case I'm raising below but couldn't find anything related.

Hello Symfony team, hello all contributors,

I'm encountering a scenario with make:form that I believe could benefit from a more nuanced handling of entity properties. In my project, I initialize a "date" field in the entity's constructor with the server’s current date. The issue is that when I generate the form using make:form, the command doesn't detect that this field is pre-initialized, so it adds the field to the form via the ->add method.

The problem in brief: (I'm running Symfony 7.2.4)

1 - Entity Initialization: The entity’s constructor sets a "date" property to the current server date.
2 - Form Generation: make:form doesn't account for this pre-initialization and includes the field in the generated form.
3 - Outcome: The form, when rendered, displays the initialized date—allowing the end-user to overwrite a server-generated value.

Proposed Solution:

It would be useful if Symfony's form generation logic could detect when a property is initialized in the entity's constructor and then adjust the generated form accordingly. For example, the generator could:

1 - Comment Out the Add Statement: Automatically comment out the ->add call for such fields in the generated form class.
2 - Include a Helpful Comment: Insert a comment like, “Property already initialized in the constructor. Uncomment the ->add statement if you want the field to be editable.”
This approach would prevent accidental user overrides of values that should remain server-controlled, while still giving developers an explicit option to make the field editable if desired.

EDIT: isn’t just about convenience—it’s also about data integrity

Questions for the community:

Is this a viable enhancement for the MakerBundle or form generation process?
Are there any potential downsides or edge cases with detecting and commenting out such fields automatically?
Could there be an alternative approach that ensures the server-generated values are preserved without hindering the developer’s control over form behavior?
Any insights, feedback, or alternative suggestions would be greatly appreciated!

Thanks in advance for reading and for your feedback.

Example

No response

[stof]

Note that a value set in the constructor does not always mean that the value should not be editable (it might be about providing a default value). I don't think we can find a solution generated the expected code for every projects automatically.

make:form is about generating some code to go quicker, but you are always free to modify it after the fact to adapt it to your actual need. The generated code is fully yours.

[halfpass25]

Note that a value set in the constructor does not always mean that the value should not be editable (it might be about providing a default value). I don't think we can find a solution generated the expected code for every projects automatically.

make:form is about generating some code to go quicker, but you are always free to modify it after the fact to adapt it to your actual need. The generated code is fully yours.

Thanks for your reply! I see your point and in a larger perspective I agree that make:form yelds us a good job, as well as I completely agree that any given form's field could be provided with a default value.
In the particular case I submitted, I have stated that the property holds a server's provided value, which usually is not intended to be modifed manually.
Maybe for the "date" field's type initialized at constructor, it could be still a good idea at least to raise a warning to the developer. If not in the codebase, at least through just a comment in the produced form's class.
If nothing of this is possible, at least I tried to highlight what to me has been a caveat and we will continue editing our files manually.