ping @webmozart

I have rebased this PR according to the last changes. ping @webmozart

Should I close it and reopen it against the 2.7 branch?

Sorry for the late reply. I like your work @egeloen! I'm 👍 for this except for a few things:

• I think you misspelled "deferred" as "differred". That had me confused a bit.
• Please remove FormOrdererInterface and the injection point of the orderer. I think the FormOrderer should be instantiated in ResolvedFormType directly. For me, this is an implementation detail that should not be exchangeable.
• The doc blocks in FormOrderer don't help a lot. You don't need to write super long descriptions, but can you add a few sentences that explain what each method is doing? That's not entirely obvious.

With these changes and a rebase on 2.8, I'm happy to merge this. :)

@egeloen Are you still interested in finishing this one?

It was not clear to me what was the position of the symfony team about this feature. If we all agree, i can indeed finish it :)

@webmozart said he was ok, so I think we can go ahead and add this feature.

@fabpot @webmozart I have rebased the PR as well as applied your comments. I'm not sure I can add a method to an interface according to the BC promise. Am I allowed? Additionally, the failling build seems unrelated. Anyway, let's review it.

Adding a method on an interface is not possible. If that makes sense (I haven't reviewed the PR), you can add a new interface.

@fabpot Okay, so this PR still need some work as I'm adding methods to existing interfaces. @webmozart How would you name this new interface?

@egeloen Use a semi-random interface name for now so that we can move forward. Renaming it to something won't be that difficult.

@fabpot Done

Is position option supported for Symfony\Component\Form\FormInterface::add?

Although I agree such a feature would be great, I don't think the implementation should be at the builder level. My guess is that should be done at the FomView level.

Having an order or another only impacts templates, and one could need different orders for different templates. Thus this should not lead to different building processes but different rendering.

I thinks it should done in all level builder, view, form.children especially form.children for sometime we want to submit some children before/after another children, most of times some field depended on others so ordering on form.children level will make it easy without re-build form.

@liverbool In which case do you need an order on submission?

If you have dependent fields, you should use listeners to rely either on submitted data (PRE_SUBMIT) or model data (POST_SUBMIT).
But the order of the fields of the submitted data array should not be responsible for changing the global behavior (e.g building) of the form.

@HeahDude First i'm not Symfony Guru ;)

Refer to symfony-cmf/media-bundle#9

Common case check for deletion

form:
    checkbox: remove_image
    image: image_field
    addEventListener(): check is remove_image checked

# We need to add addEventListener to every root form that contains image field.

My case

form:
    checkbox: remove_image
    custom_image: image_field
        addEventListener(): "can't check is remove_image checked"

# I need to add addEventListener to custom custom_image but i can't get submitted state of remove_image checkbox.

My solution

form:
    custom_image: image_field # compound field
        image: truly_image_field
        checkbox: remove_image
        addEventListener(): (check is remove_image checked)
        addModelTransformer(): (transform truly_image_field to model)

My discussion

custom_image: image_field
    addEventListener(): 
        - add remove_image to root form by making it's submition fire before custom_image field
        - check is remove_image checked when make sure remove_image was submitted first

form:
    custom_image: image_field

@liverbool Let's not mix submission and fields ordering.

I really think that a submission depending on the fields order is very fragile. The solution you wrote is the way to go: a custom type with a specific needs so with event listeners, data transformers and data mappers when useful.

@HeahDude I agree order submission quite weak but we can guarantee the ordering by using build position order by programmatic

I'm a bit late to the party. Sorry.

One could argue that field order is presentation logic. Outside of their presentation, field order doesn't really matter to a form. HTTP doesn't care, relational databases don't generally care. Can't comment about nosql, perhaps field order is a concern there.

With that in mind, perhaps having field ordering in the form is not the way to go. A mechanism for sorting children within FormViews seems a little more abstracted.

$builder->add('field1');
$builder->add('field2');

...

$builder->add('field3');

...

$view->orderChildren(['field1', 'field3', 'field2']);

This will probably be very simple to implement as it's just an array manipulation.

It also allows one to easily specify the sorting in a template:

{{ form.orderChildren(['field1', 'field3', 'field2]) }}

Seems more MVC to keep presentation logic in the view, and it might not cause any BC breaks.

Adding this method to FormView works:

    public function orderChildren($fields)
    {
        $children = $this->children;
        $_children = array();

        foreach($fields as $field) {
            if(isset($children[$field])) {
                $_children[$field] = $children[$field];
                unset($children[$field]);
            }
            else {
                // throw an Exception ?
            }
        }

        foreach($children as $field => $child) {
            $_children[$field] = $child;
        }

        $this->children = $_children;
    }

There's probably a nicer way to write the code. But it works.

    public function finishView(FormView $view, FormInterface $form, array $options)
    {
            $view->orderChildren(['postCode', 'emailAddress']);
    }

Or in twig:

{{ form.orderChildren(['postCode', 'firstName', 'emailAddress']) }}

I agree with @henrypenny that this is a presentation logic issue and should not be implemented in terms of FormInterface. Moreover it could even hurt custom form processing logic (via listeners), when the order of subforms in the FormInterface is manipulated from arbitrary places (3rd party form type extensions). Based on this, i dont think any changes are necessary at all, if we compare an eventual FormView::orderChildren method with the status quo:

{% form_order my_form [ 'field1', 'field2', 'field3' ] %}
{{ form(my_form) }}

vs

{% form_order my_form [ 'field1', 'field2', 'field3' ] %}
{{ form_start(my_form) }}
  {{ form_widget(my_form) }}
{{ form_end(my_form) }}

vs

{{ form_start(my_form) }}
  {{ form_errors(my_form) }}
  {{ form_row(my_form.field1) }}
  {{ form_row(my_form.field2) }}
  {{ form_row(my_form.field3) }}
{{ form_end(my_form) }}

Only the first example is significantly smaller, than the others, while also being the simplest. As soon as you start dealing with compound subforms and want to interleave their output FormView::orderChildren wouldnt be useable anymore (or any other logic outside of the template).

Closing this old PR as it does not seem that there is a consensus. Having order only at the template level seems like the best way to go.