TYPO3 Core

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.

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...

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.

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.

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?

Vasyl Mosiychuk wrote:

[...]
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?

Do you still need help? I managed to get some sys_category in the ext:form frontend via a custom formElementsDefinition (in yaml & php, mainly following this: https://daniel-siepmann.de/posts/2017/how-to-create-typo3-form-select-element-with-options-selected-from-database.html), set it to MultiSelect and used the default (but extended) SaveToDatabaseFinisher plus a following SaveToDatabaseFinisher which gets the '{SaveToDatabase.insertedUids.0}' value.

This is the logic of my second SaveToDatabaseFinisher:

        // ...

        protected function saveToDatabase(array $databaseData, string $table, int $iterationCount) {
            // ...

            $categories = explode(",", $databaseData["categories"]);
            $sorting = 0;
            foreach ($categories as $category) {
                $categoryData = [
                    "uid_local" => $databaseData["guide_id"],
                    "uid_foreign" => $category,
                    "sorting" => $sorting
                ];

                parent::saveToDatabase($categoryData, $table, $iterationCount);

                $sorting++;
            }
        }

        // ...

Have a great day!