👍

This would be great! +1

What do you think about renaming required option to something like html_required ?

@shoomyth Not much. As you see above, fields without the required attribute behave differently when they are required (e.g. choice fields, which show an empty row if not required)

👍

Yeah, required false should be default, I've had to force it in all my projects.

As an aside, it is absurd that the choice options show a (not applicable) choice by default when required is false. I want the user to pick the choices I give, and if I set required false, I'd like them to be able to skip the question without having framework generated options.

+1

I think, its very difficult to make a default guess, without any information. So for me the only answer would be, making it configurable. Perharps a DefaultGuesser might be a good idea.

Big 👍 from me from a feature-standpoint. This is one of my least favorite moments in a training - when I explain that all their fields have a "required" HTML5 attribute unless they explicitly say required => false.

So my only worry would be BC breaks and I'm thinking of the client-side variety as you eluded to. It seems minor, but if I was kind of depending on that required attribute showing up on all the fields on my site, then upgrading to 2.6 (if this were merged for that) would mean that all of my fields suddenly don't have this value. So I hate to do this, but it does feel like something that should be configurable in config.yml, with a default of the old behavior, but where we change the SE to configure to use the new value. What do you think?

@webmozart I think you somewhere also suggested an alternative solution: to add the NotNull constraint automatically when the field is required. Would this be an option?

See #3822

I'm not sure if +1 or -1.

From a UX I would say +1, as it's so annoying the fact that you have to manually set required to false on checkboxes, but this is the only case I usually have to.

The only issue I see is that for Doctrine ORM the default nullable option is set to false and that means you would have different default values for a similar concept.

Well I would say @Gladhon suggestion is a good idea, cause without we get many days working on old projects without a benefit.

@weaverryan Remember that all fields with a NotNull/NotBlank constraint or with nullable set to false (in the Doctrine mapping) will be set to required. Do you still think it's a big problem?

@Tobion Yes. That's a different issue though IMO, since it requires merging of the model and form constraints. I'm not even sure whether it's doable.

@stefanosala For properties mapped in Doctrine, the "required" option is guessed based on the value of "nullable". So fields for properties with "nullable" set to false will still be required.

@webmozart you forget that the guessing is only done when no type is given for a field. And from my experience most of the time developers explicitly set the field type. So the change will definitely have impact on many projects. But I'm still 👍 to change the default

@Tobion You're right. What about doing this change together with a fix for #7868 then?

@webmozart IMO, this should indeed wait until the guessing is improved to be usable even when specifying the type. Otherwise, it is a big BC break (if we were only loosing the client-side validation on some fields unless re-adding the option explicitly, it would be fine, as you should never trust the client-side validation anyway, but as you said, this impacts the way some forms are built too)

@stof Alright, let's do this for 2.7 then.

@webmozart Is it still true that the guessing only happens if you don't specify a field type (i.e. you allow the field type itself - like text - to be guessed)? Or have things been changed so that it'll guess required in all cases, unless you've explicitly set the option on the field? I was thinking that lots of required attributes would be lost because people are specifying their field types, and so they are not taking advantage of the guessing niceness your describing, and are instead just letting all of their field use the current default required value. But if guessing is happening now in all cases (even when the field type is given), then it would certainly affect less people.

Anyways, I'm really excited to have this improved whenever we can. But I do think there are some BC breaks here on the client side. But if we had a configuration option to toggle between the old and new default value, then maybe it's a non-issue.

@weaverryan That's still the case. That's why we need to fix #7868 before merging this.

ref #7181

👍 I'm in favor of this change. It was very weird to set required to false on field you don't want HTML5 required attribute. A lot of my past hotfix was targeting this kind of thing.

I am too, in favor of this change. But wouldn't this affect forms with children? According to https://github.com/symfony/symfony/blob/2.5/src/Symfony/Component/Form/FormInterface.php#L202 all the children's form fields would be forced non-required (even if you set them to required) if the parent is not required.
I'm having this problem right now. We have a field (called "blocks") which isn't required by itself but can contain an arbitrary number of children forms (a "block", which, when chosen to be used, has it's own required fields, depending on its type). Right now I need to set the "blocks" field to required (or don't set it at all), even if it leds the user to think she has to add some blocks. Because if I set it to required=false then all subform's fields (the different "block" forms) would be auto-set to required=false which isn't what I want because there are blocks that have required fields when chosen to be used.

Maybe this a whole other problem but setting required to false by default should also make an end to the current required=false recursion that is taking place (for reasons I didn't quite understand yet).

@webmozart required should probably be set to true automatically for the root form though, to avoid inheriting it as non-required for all fields.

Why not have an option at the formBuilder level to set a default required value for all fields in the form? Then a developer only ever uses a field's required option to override the default value set at the form level. As far as I can tell this would get around the backwards compatibility issue and, in my opinion, be clearer for devs.

@jxmallett Even if this would help to prevent a BC it doesn't seem right and a small bloat of the formBuilder interface. I still opt for the main request of webmozart which makes so more sense that how required is currently set if no validation constraint was configured (i.e., the default behavior).

What about this one @webmozart?

Closing as there is no more activity here. If anyone wants to take over, that would be great of course.