Closed supersmile2009 closed 2 years ago
About the 1., I deliberately want to keep fields as small as possible to see the important.
The Serializer component as well by example, serialize object properties in the same order of they are listed in the object. From https://github.com/a2lix/Demo/blob/master/app/src/Form/CompanyType.php#L26-L29, I prefer avoid :
'fields' => [
'title' => [],
// ... OTHER_FIELDS => []
// ... OTHER_FIELDS => []
'description' => [
'disabled' => true,
],
],
But, force the order, like above should be nice to have, it's true.
About 2., again, I deliberately want to keep fields as small as possible but it's true that it"s quite harmful on associations fields and it will need a compromise to find.
Hi @webda2l Thanks for quick response!
'fields' => [
// some field configs if necessary
],
'forceFieldsOrder' => [
'title',
'slug',
'content',
],
But then if you need to add some config to ordered fields, you end up configuring them twice:
'fields' => [
'slug' => [ //slug here
'help' => 'Some help string.'
],
],
'forceFieldsOrder' => [
'title',
'slug', // and again slug here
'content',
],
So why not to keep it simple and define fields only once?
Lets look at it from another point of view - you want to configure only one field
'fields' => [
'image' => [
// some custom configs here
'help' => 'Some help string.'
],
],
but don't want it to be the first field. Well, it means that you DO care about fields order and will have to configure order anyway. I cannot imagine a situation when anyone in this example scenario would want an image to be "any but not the first field". Because without manually configuring order, its guaranteed by virtually nothing.
That's why I see suggested (old-style) config as the best option here. But If you have other good ideas on how to achieve it, I'll be glad to help with implementation.
fields
array or if it has empty config.
E. g.
'fields' => [
'title' => [], // will use auto config, because user config is empty
'image1' => [], // will use auto config
'image2' => [
// has user-defined config, auto-config will not be added
'help' => 'Some help string.'
],
],
Again, it should preserve compatibility with apps upgrading to TranslationsFormBundle v3. Alternatively we can do one of these:
'fields' => [
'image2' => [
// a new option in a field config
'autoConfig' => false, // disable appending auto config to this field
'help' => 'Some help string.'
],
],
// or a new form type option
'disableAutoConfig' => [
'image1',
'image2',
],
I'd rather go with the first of the suggested alternatives, because if you don't want auto-config to be appended, it means that you already have a custom field config defined, so you can simply stick 'autoConfig' => false,
into it.
Or we can do it with a bundle config to enable/disable this behavior globally.
ApiPlatform and EasyAdminBundle are two other examples if you want :) Fact is previous versions of TranslationsFormBundle was thought as well to only list fields which require custom configuration and not all fields..
I see two ways:
With a default order in the Doctrine entity: slug, title, content, and a required display order: title, slug, content, we'll have:
'fields' => [
'title' = [ display_weight => -1]
'slug' => [
'help' => 'Some help string.'
],
]
It sound good to me. WDYT?
About the theme of auto configuration, I mainly see the problem for Many associations with https://github.com/a2lix/AutoFormBundle/blob/master/src/ObjectInfo/DoctrineORMInfo.php#L89-L90. Some could doesn't want _allowadd:true as default, by example. I thought in the past about add a default configuration at high level that users could update.
a2lix_auto_form:
assoc_many_collection_options_default: // Naming could be improved maybe..
allow_add: true
by_reference: false
It could be enough. Or an additional field as you suggest, like default_config:false could be added too.. to thinking..
Do you see problems with autoconfiguration, in other cases than with Many associations?
Changelog
Subject
I'm addressing 2 issues which I experienced when upgrading to TranslationFormBundle v3, which now requires this bundle. I believe these issues are going to affect anyone who is upgrading to v3, because AutoFormBundle changed translations form behaviour a lot and does not provide at the moment enough control over generated forms when it's needed.
$formOptions['fields']
and not vice-versa.ModelListType
fields. However I believe I may cause issues with a number of other use cases, when user doesn't want that automatic config appended. The changes in this PR implement suggested behaviour to respect user-defined field config.