Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for help_translation_parameters and label_translation_parameters #6206

Merged
merged 16 commits into from
Jul 22, 2020

Conversation

tkuska
Copy link
Contributor

@tkuska tkuska commented Jul 16, 2020

Subject

In Symfony 4.3 form translation was improved, there was added parameters like 'label_translation_parameters' and 'help_translation_parameters' but these parameters was missing in SonataAdmin templates

Changelog

### Added
- Support for 'help_translation_parameters' in form types
- Support for 'label_translation_parameters' in form types

core23
core23 previously approved these changes Jul 17, 2020
@jordisala1991
Copy link
Member

Build is failing, can you rebase?

Copy link
Member

@VincentLanglet VincentLanglet left a comment

Choose a reason for hiding this comment

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

I had trouble to understand this file... 🤔

Why label_translation_parameters and help_translation_parameters would be accessible like this, when we're doing sonata_admin.field_description.translationDomain or sonata_admin.field_description.help for others params ?

Shouldn't we use something like sonata_admin.field_description.option.foo ?

@VincentLanglet VincentLanglet requested a review from a team July 17, 2020 06:48
@franmomu
Copy link
Member

Why label_translation_parameters and help_translation_parameters would be accessible like this, when we're doing sonata_admin.field_description.translationDomain or sonata_admin.field_description.help for others params ?

https://symfony.com/blog/new-in-symfony-4-3-improved-form-translation, you can define them in form types.

@VincentLanglet
Copy link
Member

Why label_translation_parameters and help_translation_parameters would be accessible like this, when we're doing sonata_admin.field_description.translationDomain or sonata_admin.field_description.help for others params ?

https://symfony.com/blog/new-in-symfony-4-3-improved-form-translation, you can define them in form types.

I agree with a classic formType. But here, we're working with FieldDescription too.

Here

<span class="help-block sonata-ba-field-help">{{ sonata_admin.field_description.help|trans({}, sonata_admin.field_description.translationDomain ?: admin.translationDomain)|raw }}</span>

You can see that we're not just using help, but sonata_admin.field_description.help. Same way we're using sonata_admin.field_description.translationDomain.

There is also

{% if sonata_admin.field_description.options is defined %}
    {% set label = sonata_admin.field_description.options.name|default(label) %}
{% endif %}

So if I want to get foo, how can I know if I need to write

  • foo
  • sonata_admin.field_description.foo
  • sonata_admin.field_description.options.foo
    ?

Added access to help_tranlslation_parameters and label_translation_parameters to fieldDescription
@tkuska
Copy link
Contributor Author

tkuska commented Jul 17, 2020

Ok, rebase done, and i've added label_translation_parameter and help_translation_parameters as options to fieldDescription, now hey are accessible like:

  • help_translation_parameters (standard symfony templates approach)
  • sonata_admin.field_description.helpTranslationParameters
  • sonata_admin.field_description.options.help_translation_parameters

Is that OK?

@tkuska
Copy link
Contributor Author

tkuska commented Jul 17, 2020

ooops i messed sth up during rebase.
changes in src/Resources/views/Core/add_block.html.twig file should not be done there.

Comment on lines 463 to 471
public function getHelpTranslationParameters()
{
return $this->getOption('help_translation_parameters');
}

public function getLabelTranslationParameters()
{
return $this->getOption('label_translation_parameters');
}
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure we want to have quick getter for every option.

Shouldn't we remove them and only use
options. label_translation_parameters to access this kind of property ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, just misunderstood your comment, i thought you want it accessible via getter

So if I want to get foo, how can I know if I need to write

  • foo
  • sonata_admin.field_description.foo
  • sonata_admin.field_description.options.foo
    ?

Copy link
Member

Choose a reason for hiding this comment

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

I never correctly understood the way this file works.

What I wanted to say is that I don't know why sometimes we're using foo and sometimes we're using sonata_admin.field_description.options.foo. Which one should we use to this work properly ? And how to know this ?

We're indeed also using sonata_admin.field_description.foo sometimes but I feel like it's not a good idea to always add getter, because we need to add them to the interface (and it's a BC-break). Working with $options is easier.

In a PR I prepare for 5.0 (so in a long long time), I will try to remove some sonata_admin.field_description.foo getter.
sonata-project/SonataDatagridBundle#239

Comment on lines 139 to 142
if (isset($options['label_translation_parameters'])) {
$fieldDescription->setOption('label_translation_parameters', $options['label_translation_parameters']);
unset($options['help']);
}
Copy link
Member

Choose a reason for hiding this comment

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

I don't think we need this, all options are set by default to the $fieldDescription.

There is special behaviour for label, template etc because the data is saved in a $label, $template property instead of the $options property (don't really know why btw...).

Copy link
Member

Choose a reason for hiding this comment

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

BTW it currently introduce a bug since you're unsetting $options['help'].

Comment on lines 150 to 153
if (isset($options['help_translation_parameters'])) {
$fieldDescription->setOption('help_translation_parameters', $options['help_translation_parameters']);
unset($options['help']);
}
Copy link
Member

Choose a reason for hiding this comment

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

Same.

@VincentLanglet
Copy link
Member

  • sonata_admin.field_description.helpTranslationParameters
  • sonata_admin.field_description.options.help_translation_parameters

IMHO we should only promote sonata_admin.field_description.options.help_translation_parameters.

  • help_translation_parameters (standard symfony templates approach)
  • sonata_admin.field_description.options.help_translation_parameters

How to know which one we should use and when ? Is it always the same value ?

@sonata-project/contributors @tkuska Does someone understand something about this file ? 😅

@franmomu
Copy link
Member

Apparently, help in FileDescription was added long time ago I would say to do the job that now the help attribute does in the form type. If so, I think we could deprecate the use of help in FileDescription in favor of the form type and clean up a little bit.

@VincentLanglet
Copy link
Member

VincentLanglet commented Jul 17, 2020

Apparently, help in FileDescription was added long time ago I would say to do the job that now the help attribute does in the form type. If so, I think we could deprecate the use of help in FileDescription in favor of the form type and clean up a little bit.

If I understand correctly:

  • We should promote foo for formOptions (even if sonata_admin.field_description.options.foo has the same value).
  • Sonata-custom options are only accessible with sonata_admin.field_description.options.foo (or sonata_admin.field_description.foo if a getter is created).

This would mean that your PR was originally better without my request @tkuska, sorry. 😔

Edit: And yeah ! We should deprecate help in FileDescription.

@tkuska
Copy link
Contributor Author

tkuska commented Jul 17, 2020

OK, i will roll back to use standard label_translation_parameters and help_translation_parameters instead of fieldDescription options this evening.

Should i do something with help option too?

i heve found something like this in FieldDescriptionInterface

//    NEXT_MAJOR: uncomment this method in 4.0
//    /**
//     * Defines the help message.
//     */
//    public function setHelp(string $help): void;

It looks like 'help' option is prepared to be part of field description in 4.0?

…tion_params for checkboxed and radios too (aswell as it works with standard Symfony forms)
@VincentLanglet
Copy link
Member

VincentLanglet commented Jul 17, 2020

OK, i will roll back to use standard label_translation_parameters and help_translation_parameters instead of fieldDescription options this evening.

Thanks !

Should i do something with help option too?

If you want to, it could be great. But you should do it in another PR.

We have to

  • Replace sonata_admin.field_description.help or sonata_admin.field_description.options.help by help (or add a TODO for next major ?)
  • Deprecate the BaseFieldDescription::getHelp and BaseFieldDescription::setHelp methods
  • Deprecate the FormMapper::setHelps and FormMapper::addHelp methods
  • Update the base_standard_edit_field.html.twig
  • Same for edit_one_to_many_inline_table.html.twig
  • Same for form_admin_field.html.twig

I create an issue to not forget about this #6207
If you want to try a PR it will be great !

i heve found something like this in FieldDescriptionInterface

//    NEXT_MAJOR: uncomment this method in 4.0
//    /**
//     * Defines the help message.
//     */
//    public function setHelp(string $help): void;

It looks like 'help' option is prepared to be part of field description in 4.0?

We added this because we were already calling setHelp on FieldDescriptionInterface, the interface wasn't up to date.
But it's better to remove this and stop using setHelp.

@VincentLanglet VincentLanglet requested a review from a team July 17, 2020 20:38
@VincentLanglet
Copy link
Member

By the way, see #5820 (comment)

You could add it too.

@tkuska
Copy link
Contributor Author

tkuska commented Jul 18, 2020

OK, i will create new PR for translation parameters in filter fields and another one with help option

@VincentLanglet
Copy link
Member

OK, i will create new PR for translation parameters in filter fields and another one with help option

Thanks.

I approved this PR. As soon as another @sonata-project/contributors approve it too, we'll merge it.

@phansys
Copy link
Member

phansys commented Jul 19, 2020

I think this patch deserves some examples at /docs/reference/form_types.rst.

@VincentLanglet
Copy link
Member

I think this patch deserves some examples at /docs/reference/form_types.rst.

Wouldn't it better to try to support every Symfony options and refer to the Symfony documentation instead ?
I feel like this doc is a outdated duplicate of Symfony form options.

@franmomu
Copy link
Member

@tkuska have you started working on deprecating the help option? I could give it a try if you want to.

@tkuska
Copy link
Contributor Author

tkuska commented Jul 21, 2020

@franmomu no, i fighting with passing label_translation_parameters in filter fields right now so you can take this help option.

@VincentLanglet VincentLanglet merged commit ba76343 into sonata-project:3.x Jul 22, 2020
@VincentLanglet
Copy link
Member

Thanks @tkuska !

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.

6 participants