Added the helpersform_start() andform_end() which were missing before.

We discussed in#5493 whetherform_end() should also implyform_rest().@Tobion made the valid point that people might not always want to render all fields. I think this is an edge case tough, so I propose to implyform_rest() by default and make it possible to deactivate this using a variablerender_rest.

{{ form_start(form) }}   {# ... #}{{ form_end(form) }}

or

{{ form_start(form) }}   {# ... #}{{ form_end(form, { 'render_rest': false }) }}

What do you think?

Another question that remains to be answered:

With the current implementation, the attributes passed in theattr option are rendered both in the<form> tag (new) and in the<div>/<table> tag of the form (for BC).

$form = $this->createForm('my_form', $formData, array(    'attr' => array(        'id' => 'foo',        'class' => 'bar',    ),));

{{ form_start(form) }}    {{ form_widget(form) }}    <input type="submit">{{ form_end(form) }}-><form>    <div>        <!-- rows -->    </div>    <input type="submit"></form>

Solutions that come to mind:

(a) Move the rendering of the attributes from the<div>/<table> tag to the<form> tagfor the root form. This breaks BC because theform_widget() call for the root form does not output the attributes anymore then. Nested forms are not affected.

<form>    <div><!-- no attrs! -->        <!-- rows -->    </div>    <input type="submit"></form>

(b) Don't render a<div> tagfor the root form and do as in (a) for the table layout. This obviously also breaks BC. Nested forms are not affected.

<form>    <!-- rows -->    <input type="submit"></form>

(c) Don't render any attributes in the<form> tag. Maintains full BC.

<form>    <div>        <!-- rows -->    </div>    <input type="submit"></form>

Opinions?

While (c) is the best solution from a BC point of view, I think it is rather unintuitive. As a newcomer, if I put a "class" attribute on a form, I would expect it to be on the outermost<form> tag, not on some<div> within.

(a) and (b), on the other hand, break BC for those people that useform_widget() to render the complete form. I don't know how many people would be affected by this,this poll tries to gather some data about that. IMO both (a) and (b) are more intuitive and future-proof.

Added the helperform() to prototype a complete form:

{{ form(form) }}

@bschussek I think{{ form_end(form, { 'render_rest': false }) }} is fine.

And to the question about attributes: I think we shouldnot maintain BC here with c) because attributes are better applied to the parent. Using CSS you can easily select the child with#formid > div but not the other way round which would make it impossible the style the form element.
So I would say a) or b) is better than c). And a) is better than b) because in HTML 4 Strict<input> element must be within a block element like<div>. So b) would not produce valid HTML 4 Strict. This restriction is not there in HTML5 anymore but yourid validation also uses the HTML4 paradigm.
All in all, IMO the best solution is a).

And a) is better than b) because in HTML 4 Strict<input> element must be within a block element like<div>. So b) would not produce valid HTML 4 Strict.

@Tobion This is not correct. With (b), each row would still be wrapped in a<div>.

I propose to postpone the question about the wrapping<div> to a future PR.

@fabpot This PR should be mergeable.

Updated the documentation.

Hi guys!

I certainly don't mind the addition of the new features here, but I'm -1 on the BC breaks and deprecations. I don't love the deprecation ofform_enctype, and I wish theform_start andform_end things would have come earlier, as we'll have a mixture on the web (think 2.0 + 2.1 versus 2.2+ docs, blog posts, etc) of things usingform_enctype andform_rest versusform_start andform_end. Individually, I like the feature, but I'm not sure having this big change is worth it.

Also, I really really don't like the deprecation ofform->bind - this will affect far too many projects and the newform->process is just a "nice" feature, at the cost of so much BC breaking. Again, I'm not sure getting rid of the current way is worth it, but I'm also not sure that having bothform->bind andform->process is clear either.

Overall, I'd like to see these "nice" things added in a way where they can co-exist with what we have currently. These are really nice features, but there's so much code that will need to update and "education" that will need to happen because the form framework is already being used in so many places.

Thanks!

@weaverryan For reference, this PR does not contain any (immediate) BC breaks, just deprecations.

We can leave inform_enctype without too much hassle if you feel that this is a problem. It is just not necessary anymore. We can also postpone the version where we remove this feature.

$form->bind($request) was not only deprecated for cleanup purposes, but also for performance reasons. Currently,BindRequestListener is attached to and invoked for each and every form element. Upgrading this is very easy so I don't really see the necessity for leaving this in. Again, we can postpone the removal date here.

What is the point of theform_end helper if it only renders a</form> tag?
If it was implemented by a customizable block or if it rendered alsoform_rest then why not but in the current state it seems really overkill.

@jalliotform_end does also renderform_rest

@bschussek Oh right sorry... I did not refresh my page and did not see the new commits.

Really nice work @bschussek. I like the way the form component is taking. There is still a lot of work, but hey, forms are a complex thing.
So it is a big 👍 for me.

Postponed to 2.3

Reviewed again and rebased on master.

Again, the test failures on 5.3 seem unrelated to this PR. Reviewed and updated the documentation.

@bschussek the fix for 5.3 has just been merged

Rebased again.

I'm guessing that this still won't handle the case where you have the data for two forms present e.g. the http method is something different that GET, but the query part of the uri contains the data submitted in a search in a previous step. Right now you need to know the form name and get such a data from the request and then bind manually.... This becomes annoying and tedious if you need to persist this through more than one step...

@mvrhov the Form component is able to get the right data based on its name (since 2.0)

@stof
Imagine the two step wizard. The first step is a search form ($form1) with action set to GET.
Now the second step contains another form ($form2) with action set to POST and the query parameters from the$form1 are part of action uri for$form2.

However in the action that gets executed on second step you need data from both form1 and form2 to complete the action. So calling$form2->bind($request), only the $from2 will get bound.
If you also want to bind the data to$form1 then you have to do..$form->bind($request->query->get('form_name'));

@mvrhov IMO this is the wrong approach to the problem. You should not bind data that you already successfully submitted again. Instead, store the values somewhere in your session and write them into your persistence layer when you're done with the wizard.

@mvrhov if you want to bind$form, call$form->bind($request) too. There is no reason for$form2->bind() to bind$form (it does not even know that you have a second Form instance created in your code)