Story #69712: Further FormEngine development
`foreign_record_defaults` is not stored when the field hidden
You have the two tables
tx_enterprise_domain_model_address with three different types of addresses (
postal). Per default the
type select is visible in all types.
array( 'ctrl' => array( [...] 'type' => 'type', [...] ), 'types' => array( '0' => array( 'showitem' => ' --palette--;;general, --palette--;;postal, --palette--;;phone, [...] ' ), 'postal' => array( 'showitem' => ' --palette--;;general, --palette--;;postal ' ), 'phone' => array( 'showitem' => ' --palette--;;general, --palette--;;phone ' ), 'email' => array( 'showitem' => ' --palette--;;general, --palette--;;email ' ), [...] ), 'palettes' => array( 'general' => array( 'showitem' => ' type ' ), 'postal' => array( 'showitem' => ' street, [...] ' ), 'phone' => array( 'showitem' => ' phone, [...] ' ), 'email' => array( 'showitem' => ' email, [...] ' ), [...] ), 'columns' => array( [...] 'type' => array( [...] 'config' => array( 'type' => 'select', 'default' => 'postal', 'items' => array( array( 'Postal', 'postal' ), array( 'Phone', 'phone' ), array( 'Email', 'email' ), [...] ) ) ) [...] ) );
And you have the table
tx_enterprise_domain_model_person with the two columns
phones the inline record address has no type select (see its
emails leaves this as configured in the inline record table above.
array( [...] 'columns' => array( [...] 'phones' => array( [...] 'config' => array( 'type' => 'inline', 'foreign_table' => 'tx_enterprise_domain_model_address', 'foreign_types' => array( 'phone' => array( 'showitem' => ' --palette--;;phone ' ) ), 'foreign_record_defaults' => array( 'type' => 'phone' ), [...] ) ), 'emails' => array( [...] 'config' => array( 'type' => 'inline', 'foreign_table' => 'tx_enterprise_domain_model_address', 'foreign_record_defaults' => array( 'type' => 'email' ), [...] ) ) ) );
After creating a person and adding a new phone number and a email for that person, you see for each inline record the correct form; for
phones this is only the input for a phone number, for
emails this is the
type select and a input for the email itself. But after saving the
type value for the
phones inline record is
postal and not
phone. So in this case
foreign_record_defaults is only correctly stored when the corresponding field was rendered before. But the expectation would be that all values in
foreign_record_defaults are stored in any case no matter if they rendered before or not.
Updated by Christian Kuhn about 5 years ago
ok, thinking about that, here is the whole picture:
for "usual" rows that are not in an inline relation where parent sets foreign_record_defaults, the same issue would happen. But it does not, because fields that have default values but are also not rendered and thus their values not transferred, BUT the DataHandler (i guess, didn't dig into) probably applies "default" config again if creating a new row and no value is set.
For inline with foreign_record_defaults this does not happen in DataHandler (DH does not know about the parent state with these details), the field is not rendered, value not transferred and DataHandler just sets the value to the default defined for the child tca field if given.
The fun part is that FAL suffers from the same issue: FAL relations have a couple of fields in a "filePalette" (uid_local, hidden, sys_language_uid, l10n_parent) and this palette is set to "isHiddenPalette = TRUE". This way, those fields are always rendered and transferred, but never shown.
While this "solution" is hilariously ugly, it will solve your issue for now by just creating such a hidden palette, too and adding "type" to it.
The "real" solution is do-able within the data provider of FormEngine: Add "columnsToProcess" array with fields that have defaults but are not within showitems/palettes within one of the according data providers. next, append those fields to showitem and override their processedTca to renderType=hidden. The default values itself are already set by one of the default value data providers. Thus, you'll end up with an additional hidden field per not-rendered field. In effect, probably the "hidden palette" stuff can be finally removed, reducing the FAL HTML overhead quite a bit, and the dataHandler could get its default handling removed and we could deprecate the "isHiddenPalette" stuff.
Updated by Susanne Moog 8 months ago
- Status changed from New to Closed
Since there were no further reports of this issue and there is an existing workaround, I'm going to close this issue now - if those parts get refactored at a later point by the datahandler intiative, these issues can be revisited.