[twig] form_enctype deprecated #12333

masterkaos · 2014-10-27T15:50:29Z

Not sure if this is the right place to comment on your best practices book, if it isn't please inform me on where to put this comment.

I just read through your best practices book, and in it it mentions
""BEST PRACTICE
Don't use the form() or form_start() functions to render the starting and ending
form tags."

And right in the example above it it uses the form_enctype function, which was deprecated in 2.3 and to be removed in 3.0. The docs say we should use form_start instead

weaverryan · 2014-10-27T16:27:46Z

You're right - it says form_enctype is scheduled to be removed in 3.0.

I prefer writing my form tag myself (obviously, inline with the best practice). So, should we:

A) Not deprecate/remove form_enctype
or
B) Deprecate/remove it and tell people to write this themselves if they're writing their form tag manually?

masterkaos · 2014-10-27T16:40:44Z

What was the reasoning on deprecating form_enctype? Is there a PR that discusses why?

I have changed the way I have done some things to follow best practices because they just make sense. However, I will most likely continue to use form_start because I do not agree with "it takes away clarity". What can be more clear than form_start. It does exactly what it sounds like, and the benefits are you do not have to remember/worry about if there is a file upload or not, not worry about names, etc.

weaverryan · 2014-10-27T17:02:33Z

The rationale was that writing your form tag isn't hard. Of course form_start isn't hard either... unless you need to add a class or some other attribute (well, not hard, but ugly and non-obvious - i.e. You need to read the docs to know how).

On the other hand, enctype is more manual, and there's also a little weirdness since your form object is programmed to respond to a certain HTTP method, which you then repeat in the template.

So, I prefer to write my form tag, since adding an attribute is so simple. That being said, I'm not totally happy with the form flow - it's a bit ambiguous because we have 2 ways of doing things (setting method +action in form and using form_start or doing things manually).

Anyways, I appreciate the conversation :).

Cheers!

mayeco · 2014-10-28T04:00:12Z

I think this is a matter of opinions and not a issue, personally I like to use form() or form_start / form_row / form_rest / form_end to render my forms I dont like to render my forms manually.

masterkaos · 2014-10-28T04:16:37Z

Well the issue is is that there is conflicting information between the docs (form_enctype deprecated use form_start) and the best practices(don't use form_start use form_enctype). I personally am going to stick with form_start because I don't want to worry about rendering manually either.

Ryan thanks for the info. I see where you coming from, but you have same issue with form widgets.

Always regarding option a or b I am not sure the better option since I am going to stick with form_start but interested to hear others thoughts.

weaverryan · 2014-10-28T06:06:26Z

You're right about having the same issue with form_widget, but that's unavoidable - and form_widget gives you a lot of functionality - whereas form_start only gives you the enctype (and the action+method if you like setting those in your form, which I don't like personally).

@javiereguiluz I'd love to know your thoughts on this :)

javiereguiluz · 2014-10-28T21:37:56Z

@weaverryan to be honest, I'm 50-50 on this issue:

Writing the <form> tag by hand it's very easy and it feels natural ... but it's also boring and doesn't go well with the idea of letting Symfony manage the forms.
Using form_start() is very fast and convenient ... but the syntax to add simple things as CSS classes is ugly.

webmozart · 2014-10-31T11:31:02Z

In my opinion, the best practices are wrong here and should be fixed. form_start() and form_end() should be used for various reasons:

Controllers are responsible for managing the control flow within an application, templates aren't. Hence, a form's action and method should also be defined in the controller by passing the "action" and "method" option when creating the form (not in the form type).
handleRequest() actually relies on the "method" being set correctly. Setting the "method" option to a different value than the "method" attribute in the HTML will prevent the form from being submitted correctly.
form_end() does not just render the form's end tag, but also any unrendered (especially hidden) fields. This prevents bugs caused by missing fields, which are hard to debug, since hidden fields are not supposed to be visible.

I personally don't recommend to render form tags manually. This will only lead to unnecessary bugs.

but the syntax to add simple things as CSS classes is ugly.

This problem applies to all form elements and is a separate issue. I agree that this should be fixed.

weaverryan · 2014-10-31T15:03:23Z

@webmozart After thinking about this awhile, I agree with you. You have listed a lot of pro's for doing things this way, and I think the cons are less (difficult/ugly to add an attr to the form tag and also feels a little weird to not physically see a <form in your template). So, I think we should propose changing this best practice.

And about my cons, I think there is some room to make them better. For example, I don't love the syntax for configuring the action and method. I would rather be able to do:

$form = $this->createForm(new FooType());
$form->setAction($this->generateUrl('foo_new'));
$form->setMethod('POST');

That's kind of like setData(). Anyways, that's feature-creep, but an idea I had - I think it's a bit prettier (and you get auto-complete) versus the options way. I'm not sure if it's possible in a BC way. Anyways, most of the time, you don't need to set the action nor the method, since it's common to POST back to the same endpoint.

Anyways, I've opened an issue about the best practice: symfony/symfony-docs#4402.

Thanks!

masterkaos · 2014-10-31T15:13:38Z

@weaverryan I love the idea of having a setAction and a setMethod methods. right now it is extremely ugly setting it in the array.
Could even have a helper shortcut method of setActionToRoute similar to how the shortcut method was added to the controller.
I love this idea so much actually, that I think I am going to create an extension class that implements
these methods and use that for now on.

I don't see why it wouldn't work BC as the options method would still be valid. I always set method and action regardless if I am submitting back to the same endpoint.

Obviously that is way out of scope of this issue but I don't think it should be forgotten about. Maybe could open an issue tagged with dx?

weaverryan · 2014-10-31T15:21:40Z

Cool! See #12368. I think setActionToRoute is a bit too magic for core, but you should definitely consider adding that to your project's base controller class if you like it :).

masterkaos · 2014-10-31T16:30:05Z

Yeah I suppose your right, as now you are adding dependency. But Ill definitely add it to my base class

webmozart · 2014-11-03T09:24:52Z

Replaced by symfony/symfony-docs#4402.

weaverryan mentioned this issue Oct 31, 2014

[Best Practice] Possible form rendering change symfony/symfony-docs#4402

Closed

webmozart closed this as completed Nov 3, 2014

rhubinak mentioned this issue Nov 19, 2021

Testing Myddleware Myddleware/myddleware#584

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

[twig] form_enctype deprecated #12333

[twig] form_enctype deprecated #12333

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

[twig] form_enctype deprecated #12333

[twig] form_enctype deprecated #12333

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!