Added the helpers form_start() and form_end() which were missing before.

We discussed in #5493 whether form_end() should also imply form_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 imply form_rest() by default and make it possible to deactivate this using a variable render_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 the attr 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 id="foo" class="bar">
    <div id="foo" class="bar">
        <!-- 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> tag for the root form. This breaks BC because the form_widget() call for the root form does not output the attributes anymore then. Nested forms are not affected.

<form id="foo" class="bar">
    <div><!-- no attrs! -->
        <!-- rows -->
    </div>
    <input type="submit">
</form>

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

<form id="foo" class="bar">
    <!-- rows -->
    <input type="submit">
</form>

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

<form>
    <div id="foo" class="bar">
        <!-- 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 use form_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 helper form() 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 should not 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 your id 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 of form_enctype, and I wish the form_start and form_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 using form_enctype and form_rest versus form_start and form_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 of form->bind - this will affect far too many projects and the new form->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 both form->bind and form->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 in form_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 the form_end helper if it only renders a </form> tag?
If it was implemented by a customizable block or if it rendered also form_rest then why not but in the current state it seems really overkill.

@jalliot form_end does also render form_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)