Bug #85772

EXT:form SaveToDatabaseFinisher cannot handle multi value fields

Added by Vasyl Mosiychuk about 1 year ago. Updated 4 months ago.

Status:
New
Priority:
Could have
Assignee:
-
Category:
Form Framework
Target version:
-
Start date:
2018-08-07
Due date:
% Done:

0%

TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

[..]
        properties:
          options:
            1: 'Label 1'
            2: 'Label 2'
        type: MultiSelect
        identifier: categories
        label: 'Multi select'
        defaultValue:
          - '2'
[...]
          uid_foreign:
            value: '{SaveToDatabase.insertedUids.0}'
[...]

If I save only one value and not empty, work it. If a value more one it not work

I mean this is about `type: MultiSelect` and `type: ImageUpload`.
How to work with `SaveToDatabase` if I to pass for saving in the DB not one value and two value or three and more


Related issues

Related to TYPO3 Core - Task #85216: EXT:form SaveToDatabase Finisher saves files as sys_file, not as sys_file_reference Closed 2018-06-11
Related to TYPO3 Core - Feature #85378: EXT:form option for saving uploaded file as sys_file_reference New 2018-06-25

History

#1 Updated by Vasyl Mosiychuk about 1 year ago

  • Related to Task #85216: EXT:form SaveToDatabase Finisher saves files as sys_file, not as sys_file_reference added

#2 Updated by Vasyl Mosiychuk about 1 year ago

  • Related to Feature #85378: EXT:form option for saving uploaded file as sys_file_reference added

#3 Updated by Susanne Moog about 1 year ago

  • Subject changed from I can not saving in the DB values if I pass for saving in the DB not one value and two value or three and more? to EXT:form SaveToDatabaseFinisher cannot handle multi value fields

#4 Updated by Susanne Moog about 1 year ago

  • Target version changed from 9.4 to Candidate for patchlevel

#5 Updated by Bjoern Jacob 6 months ago

  • Sprint Focus set to Remote Sprint

#6 Updated by Susanne Moog 5 months ago

The SaveToDatabase finisher was originally meant to provide a starting point for custom implementations and is therefor currently not capable of rendering all possible fields and combinations. In stable releases it should be used for very simple forms or as code tutorial on how to develop own finishers.

For future versions we need to define a concept of how and what we want to ship with the core.

#7 Updated by Michael Waack 5 months ago

  • Assignee set to Michael Waack

#8 Updated by Michael Waack 5 months ago

  • Assignee deleted (Michael Waack)

#9 Updated by Bjoern Jacob 5 months ago

  • Sprint Focus deleted (Remote Sprint)

#10 Updated by Vasyl Mosiychuk 5 months ago

Susanne Moog wrote:

The SaveToDatabase finisher was originally meant to provide a starting point for custom implementations and is therefor currently not capable of rendering all possible fields and combinations. In stable releases it should be used for very simple forms or as code tutorial on how to develop own finishers.

For future versions we need to define a concept of how and what we want to ship with the core.

In to manual not said nothing about that the `ext:from` ... should be used for very simple forms or as code tutorial on how to develop own finishers, as for a non-technical editor, so and as an experienced integrator.

I think the `ext:form` is should provide possibility to save all data in the database which sent from the form.

In this case TYPO3 and the `ext:from` will be available for all users, and really will be simple and easy...

#11 Updated by Bjoern Jacob 5 months ago

  • Target version deleted (Candidate for patchlevel)

If you want to store the form data in your database, try this extension: https://github.com/pagemachine/typo3-formlog.

#12 Updated by Vasyl Mosiychuk 5 months ago

Bjoern Jacob wrote:

If you want to store the form data in your database, try this extension: https://github.com/pagemachine/typo3-formlog.

No, this is not that what need...

I need save data in the table of database for example extension news or other extension where is in the record has more one category and more one images.

#13 Updated by Susanne Moog 5 months ago

The problem is, we will not be able to support arbitrary use cases. One use case could be to have categories as csv - kind of a log entry -, the next wants the categories created and saved as 1:n relation, next is m:m relation and so on. We have no secure way of figuring out what kind of form people are building and guessing will make the situation worse. Trying to support any kind of datastructures will be extremely complicated, quite impossible to get right and complex - whereas creating an own finisher for your specific case should be a lot more straightforward, as you - and only you - know exactly what you are building and what the logic should be for the relations.

The only reliable configuration source we have for tables with relations at the moment would be TCA, which would essentially mean, rebuilding form engine (backend forms) for the frontend - that however would not be a task for the form framework, but rather a separate package.

#14 Updated by Vasyl Mosiychuk 4 months ago

Susanne Moog wrote:

The problem is, we will not be able to support arbitrary use cases. One use case could be to have categories as csv - kind of a log entry -, the next wants the categories created and saved as 1:n relation, next is m:m relation and so on. We have no secure way of figuring out what kind of form people are building and guessing will make the situation worse. Trying to support any kind of datastructures will be extremely complicated, quite impossible to get right and complex - whereas creating an own finisher for your specific case should be a lot more straightforward, as you - and only you - know exactly what you are building and what the logic should be for the relations.

The only reliable configuration source we have for tables with relations at the moment would be TCA, which would essentially mean, rebuilding form engine (backend forms) for the frontend - that however would not be a task for the form framework, but rather a separate package.

...and there are not so many cases, mainly it is "categories" and "tags" and "sys_file_reference".

at least core "sys_category" and "sys_file_reference" would be well

I think, that need describing in the documentation about those cases. Can you describe in documentation create own finisher for this case as an example?

Also available in: Atom PDF