This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.
Go to file
Nyholm b2f269e430
feature #40690 [Form] Add support for sorting fields (yceruto)
This PR was squashed before being merged into the 5.3-dev branch.

Discussion
----------

[Form] Add support for sorting fields

| Q             | A
| ------------- | ---
| Branch?       | 5.x
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       | Fix #5827
| License       | MIT
| Doc PR        | TODO

This PR adds a new `priority` option used later to sort all fields in order of importance instead of simply numerical order, i.e. fields with higher priority will be rendered first, fields with lower priority will be rendered last. The default priority would be "0" for all fields. Fields with equal priority will keep the original order (stable sorting).

History of previous proposals and discussions: #3452, #4254, #5827, #6111, #11241

This kind of feature has been abandoned in the past because complex proposals, and somehow rejected because ideally we should do the sorting at the view level ([customizing form](https://symfony.com/doc/current/form/form_customization.html) themes or layout templates) and it's true for most cases (the simple ones I think) but the fact is that it's often quite complex to accomplish that way, mainly for [dynamic forms](https://symfony.com/doc/current/form/dynamic_form_modification.html).

Let's focus the following analysis on explaining *why* and *when* the `priority` option could save us a lot of time, getting rid of cumbersome workarounds with templates to change the rendering order *only*.

---

A common example could be the building of a multi-steps form with a convenient type hierarchy and including fields dynamically based on the data. Let's take this sample:

![image](https://user-images.githubusercontent.com/2028198/113465635-a5a81180-9403-11eb-839f-3a32d5f84f47.png)

```php
class WorkflowType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        // get current enabled transitions from the workflow definition...

        foreach ($enabledTransitions as $transitionName) {
            $builder->add($transitionName, SubmitType::class, ['attr' => ['value' => $transitionName]]);
        }
    }
}

class PersonRegistrationType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('firstName')
            ->add('lastName');

        $builder->addEventListener(FormEvents::PRE_SET_DATA, function (FormEvent $event) {
            $person = $event->getData();

            if ($person->isLegalType()) {
                $event->getForm()->add('company');
            }
        });
    }

    public function getParent()
    {
        return WorkflowType::class;
    }
}
```
These classes model the required form. However, according to the form building process and taken into account that the underlaying person data was set with "legal" type (from the previous step), this will be the rendering result:
```html
<button type="submit" name="form[register]" value="register">Register</button> {# wrong place #}
<input name="form[first_name]">
<input name="form[last_name]">
<input name="form[company]">  {# wrong place #}
```
Now, taking the view customization path to fix the order, you likely will face some problems regarding to:
 - How do I render the dynamic submit buttons at the bottom?
 - How can the specific form fields be rendered in the correct order if they vary from step to step? (being it a generic template)
 - if you solve the previous questions, you will also need to check if the company field is defined or not before rendering it in the right order.

There could be more and different problems depending on the context and you can find workarounds using the block prefixes system to customize each step block theme, but to me it's enough to think about other alternatives.

On the other side, using the `priority` option, the solution is quite easy. Setting the right priority value will guarantee the right rendering order:
```php
// ...
$builder->add($transitionName, SubmitType::class, ['priority' => -1, // ...]);

// ...
$event->getForm()->add('company', null, ['priority' => 1]);
```
That's ! There is no need to customize templates at all when you only need to change the fields order.

This way, these fields are being pre-defined in the order they will be rendered at view level. This sorting process will take place on `$form->createView()` method, just after `buildView()` and before `finishView()` calls.

Could we reconsider the usefulness of this feature? please.

Cheers!

Commits
-------

62650bbdc7 [Form] Add support for sorting fields
2021-04-14 11:13:37 +02:00
.github [CI] Make sure packages contain all metafiles 2021-04-08 08:41:25 +02:00
src/Symfony feature #40690 [Form] Add support for sorting fields (yceruto) 2021-04-14 11:13:37 +02:00
.appveyor.yml Merge branch '4.4' into 5.2 2021-02-16 11:13:48 +01:00
.editorconfig Update .editorconfig 2018-09-06 16:22:56 +02:00
.gitattributes [Runtime] a new component to decouple applications from global state 2021-03-09 21:44:54 +01:00
.gitignore Run the phpunit-bridge from a PR 2019-08-02 17:46:19 +02:00
.php_cs.dist Merge branch '5.1' into 5.2 2021-01-19 22:00:40 +01:00
.travis.yml Merge branch '5.2' into 5.x 2021-03-23 22:05:31 +01:00
CHANGELOG-5.0.md Merge branch '5.0' into 5.1 2020-06-15 13:50:15 +02:00
CHANGELOG-5.1.md Update CHANGELOG for 5.1.10 2020-12-18 14:43:18 +01:00
CHANGELOG-5.2.md Update CHANGELOG for 5.2.6 2021-03-29 07:16:50 +02:00
CODE_OF_CONDUCT.md Added the Code of Conduct file 2018-10-10 03:13:30 -07:00
composer.json Drop support of mercure:^0.4 2021-04-06 11:32:33 +02:00
CONTRIBUTING.md Mention the community review guide 2016-12-18 22:02:35 +01:00
CONTRIBUTORS.md Update CONTRIBUTORS for 4.4.21 2021-03-29 07:10:41 +02:00
LICENSE Bump license year 2021-01-01 10:24:35 +01:00
link Merge branch '5.1' into 5.2 2020-12-10 20:16:15 +01:00
phpunit Merge branch '4.4' into 5.2 2021-02-11 09:21:20 +01:00
phpunit.xml.dist Merge branch '4.4' into 5.1 2020-11-16 16:58:32 +01:00
psalm.xml Adding a Github action to run Psalm 2021-02-25 17:18:18 +01:00
README.md Update README.md 2021-04-04 16:42:37 +02:00
UPGRADE-5.0.md Merge branch '4.4' into 5.1 2020-12-10 18:44:54 +01:00
UPGRADE-5.1.md Update UPGRADE-5.1.md 2020-09-07 01:58:27 +02:00
UPGRADE-5.2.md [HttpFoundation] Deprecate BinaryFileResponse::create(). 2020-11-20 16:47:02 +01:00
UPGRADE-5.3.md [Security] Fix UsageTrackingTokenStorage outside the request cycle 2021-04-13 08:27:14 +02:00
UPGRADE-6.0.md [Console] Deprecate Helper::strlen() for width() and length() 2021-04-09 11:54:15 +02:00

Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Symfony is used by thousands of web applications (including BlaBlaCar.com and Spotify.com) and most of the popular PHP projects (including Drupal and Magento).

Installation

Documentation

Community

Contributing

Symfony is an Open Source, community-driven project with thousands of contributors. Join them contributing code or contributing documentation.

Security Issues

If you discover a security vulnerability within Symfony, please follow our disclosure procedure.

About Us

Symfony development is sponsored by SensioLabs, led by the Symfony Core Team and supported by Symfony contributors.