[FEATURE] Centralize TCA to allow modification, resolves #382

[d-s-codappix]

Resolves: #382

[d-s-codappix]

Example usage: Services.yaml:

services:
  _defaults:
    autowire: true
    autoconfigure: true
    public: false

  Vendor\ExtName\Import\DynamicTcaRepository:
    decorates: Cobweb\ExternalImport\Domain\Repository\TcaRepositoryInterface
    public: true

PHP Class:

<?php

namespace Vendor\ExtName\Import;

use Cobweb\ExternalImport\Domain\Repository\TcaRepositoryInterface;
use TYPO3\CMS\Core\Database\ConnectionPool;

final readonly class DynamicTcaRepository implements TcaRepositoryInterface
{
    public function __construct(
        private TcaRepositoryInterface $parent,
        private ConnectionPool $connectionPool,
    ) {
    }

    public function getTca(): array
    {
        $tca = $this->parent->getTca();

        // Do some magic via database

        return $tca;
    }
}

[fsuter]

Hi. I'm finally taking the time to look seriously at your PR. I also needed to read more about the Schema API first, since you hinted that your proposed change could ease switching to the Schema API later.

I'm basically okay with your change. I would rather go the way of introducing a PSR-14 event for changing the TCA. I think DI is poorly understood (including by myself, in part because - my judgment - the documentation about that part is not helpful).

I'm wondering if the repository should really be so simple, of if it should include more precise methods, like getCtrlConfiguration or getConfigurationForField, in order to reduce the array accesses in the code. What do you think?

And related to the Schema API, as it stands and if I understand correctly, it would not be usable in External Import, because it would not make it possible to access the "external" configuration. The Schema API exposes only selected parts of the TCA. Is this also how you understand the situation?

[d-s-codappix]

Hi. I'm finally taking the time to look seriously at your PR. I also needed to read more about the Schema API first, since you hinted that your proposed change could ease switching to the Schema API later.

Thanks for looking into that. I highly appreciate a proper preparation with a working concept instead of a fast implementation that needs to be changed over and over again. I didn't have a closer look into Schema API yet. But it should be read only. The extension itself would need something else in order to allow modification of the configuration. Still a single location for accessing the systems configuration should make it easier.

I'm basically okay with your change. I would rather go the way of introducing a PSR-14 event for changing the TCA. I think DI is poorly understood (including by myself, in part because - my judgment - the documentation about that part is not helpful).

I'm fine with either DI or PSR-14 approach. I'd leave it up to you as maintainer of the extension.

I'm wondering if the repository should really be so simple, of if it should include more precise methods, like getCtrlConfiguration or getConfigurationForField, in order to reduce the array accesses in the code. What do you think?

I guess that would be a good idea. Another one would be to turn the Class into a Factory that will trigger the event. The factory can return an internal object with proper API. That way the extension is independent of concrete TYPO3 concepts.
Only the factory and EventListener need adoption to adopt to the TYPO3 changes and still return the necessary information/object.

And related to the Schema API, as it stands and if I understand correctly, it would not be usable in External Import, because it would not make it possible to access the "external" configuration. The Schema API exposes only selected parts of the TCA. Is this also how you understand the situation?

That might be the case right now, I'm not too much into that topic. It might be possible to open the API in the future. But I also could imagine that it should be kept that small to not be bloated again.
I don't see a need to adopt to Schema API within v13 or v14 yet. But one could use it in case it makes things easier.
E.g. the factory imagined above can use both, TCA and Schema API to build the final instance of an internal class for the extension.

I hope those comments and ideas are helpful.

[fsuter]

Thanks for your answer. It will help me move forward. I also mean to check with the Core Team what their plan is with the Schema API, but - as you said - if the code is well wrapped, it does not matter so much.