Skip to content

Access to CollectionType options in AdminType#6438

Merged
VincentLanglet merged 1 commit intosonata-project:3.xfrom
VincentLanglet:wip
Oct 23, 2020
Merged

Access to CollectionType options in AdminType#6438
VincentLanglet merged 1 commit intosonata-project:3.xfrom
VincentLanglet:wip

Conversation

@VincentLanglet
Copy link
Member

@VincentLanglet VincentLanglet commented Oct 1, 2020

This is related to #6426 (comment)

I need to know the CollectionType value of by_reference in the AdminType.

The options are passed to the AdminType here:
https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/3.x/src/Builder/FormContractor.php#L172-L180

So I need to change the signature of getDefaultOptions to allow passing the formOptions.

But then I have two solutions:

  • Option 1: Adding a new symfony_form_options option to the AdminType, then in the FormContractor I will add
$options['symfony_form_options'] => $formOptions

And then I access to by_reference with $options['symfony_form_options']['by_reference'] ?? true.

  • Option 2: Using the by_reference option of the AdminType, then in the FormContractor I will add
if (isset($formOption['by_reference'])) {
    $options['by_reference'] => $formOptions['by_reference'];
}

And then I access to by_reference in the AdminType with $options['by_reference'].

WDYT @sonata-project/contributors ?

In this PR I have implemented the code for the solution 1, but passing all the options seems overkill to me and I think the solution 2 more elegant.

Changelog

### Fixed
- AdminType with CollectionType passed by reference

@wbloszyk
Copy link
Member

wbloszyk commented Oct 4, 2020

IMO When you exnteds AbstractType then you should have symfony options directly in $options. Also in case you can add own options to $options or `$options['sonata'] and never vice versa (never $options['symfony']). This will make usage more logic.

I vote for option 2 😆

@SonataCI
Copy link
Collaborator

SonataCI commented Oct 4, 2020

Could you please rebase your PR and fix merge conflicts?

@VincentLanglet VincentLanglet marked this pull request as ready for review October 12, 2020 19:17
@VincentLanglet VincentLanglet requested a review from a team October 12, 2020 19:19
@VincentLanglet
Copy link
Member Author

Please review this bug fix @sonata-project/contributors

@VincentLanglet VincentLanglet requested a review from a team October 19, 2020 06:49
jordisala1991
jordisala1991 previously approved these changes Oct 19, 2020
@jordisala1991
Copy link
Member

Tests are failing now

@VincentLanglet
Copy link
Member Author

Fixed @jordisala1991

@VincentLanglet VincentLanglet requested a review from a team October 19, 2020 09:47
// Note that the builder var is actually the formContractor:
$options = array_replace_recursive($this->builder->getDefaultOptions($type, $fieldDescription) ?? [], $options);
$options = array_replace_recursive(
$this->builder->getDefaultOptions($type, $fieldDescription, $options),
Copy link
Member

@franmomu franmomu Oct 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably I'm missing something, but why do we need to pass the form options to the builder (persistence bundles) if we already have them here?

Apparently https://github.com/sonata-project/SonataDoctrineORMAdminBundle/pull/1142/files this just adds the by_reference to the array.

Copy link
Member Author

@VincentLanglet VincentLanglet Oct 20, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because they are transformed.

From

$options = ['by_reference' => true];

To

$options = [`type_options` => ['by_reference' => true]]

(And multiple others modifications)

And the options passed are not always the same ; the depends on the type, etc
It the responsibility of the persistence bundle to re-format the options.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember some unintended behavior regarding these options (#6078).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure to understand. ^^'
Is it an answer to franmomu ? A request change to me ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry. The comment is regarding the modifications you've mentioned about the options.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reasoning seems fine to me.
I just have a concern. Since we are adding a 3rd argument in order to fix this issue properly in the next major, shouldn't be better to provide the fix by using this new argument through func_get_args() and deprecate the case where it's considered required and not used?
I didn't see how this new argument will be used in the method, so in case my previous concern can not be done, I think at least we should leave the comment with the code fragment that must be uncommented in the next major.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand @phansys.

To me, the only NEXT_MAJOR comment needed is https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/3.x/src/Builder/FormContractor.php#L101

The 3rd argument will always be used from now, so I don't understand why you want to deprecate it ?
This is a long term fix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 3rd argument will always be used from now, so I don't understand why you want to deprecate it ?

I'm not saying we should deprecate the argument, please re-read my comment:

deprecate the case where it's considered required and not used

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me, the only NEXT_MAJOR comment needed is https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/3.x/src/Builder/FormContractor.php#L101

Sorry, didn't see that the call to func_get_args() and the NEXT_MAJOR comment were already there before this PR.

I think then we should just trigger a deprecation if the FormContractor::getDefaultOptions() method is called without the 3rd argument. Do you think it could be done in this PR?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The getDefaultOptions is implemented in persistence bundle, so I can't do it in this SonataAdmin PR.

But I can create PR on persistence bundle then.

@VincentLanglet VincentLanglet requested review from a team and franmomu October 20, 2020 19:40
@VincentLanglet VincentLanglet mentioned this pull request Oct 22, 2020
@VincentLanglet
Copy link
Member Author

@franmomu Can we merge this bugfix and decide after if we need and how to refactor getDefaultOptions ?

@VincentLanglet
Copy link
Member Author

Please review @sonata-project/contributors

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants