A place to put the business logic

[Moongazer]

Not sure if this is an issue, but as far as I can see only classes which extend Extbase's AbstractDomainObject can deliver content over the API. That makes me wonder how or where to define business logic (the model should not contain such, right?).

As example, lets say I need to have an endpoint which receives a complex setting-object. The settings are stored in multiple tables, so usually a controller or service has do handle this. Another usecase is how to make aggregated/calculated database values available? Like a statistic-endpoint which gives back aggregated values based on a custom SQL query using SUM/AVG functions (logic from a repository).

I took a look to the t3apinews example, but could not find any logic there. Can t3api handle such cases or is it not made for it (yet)?

[kszymukowicz]

Support for custom endpoints with own controller is already done in branch https://github.com/sourcebroker/t3api/tree/issue-7 but needs to be yet rechecked before merging to master.

In short you need to register handler in ext_localconf.php

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['t3api']['operationHandlers'][\V\Myext\OperationHandler\Operation1Handler::class] = 100;
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['t3api']['operationHandlers'][\V\Myext\OperationHandler\Operation2Handler::class] = 100;

The 100 is priority if there is more implementation of the same endpoint.

Then create a model for business logic (in this model you will define possible endpoints with annotations)
(Classes/Domain/Model/Logic1.php)

/**
 *
 * @T3api\ApiResource (
 *     itemOperations={
 *          "operation1"={
 *              "path"="/logic1/something1",
 *              "method"="GET",
 *          },
 *          "operation2"={
 *              "path"="/logic1/something2",
 *              "method"="GET",
 *          }
 *     }
 * )
 */
class Logic1 extends \TYPO3\CMS\Extbase\DomainObject\AbstractEntity
{

}

And then implement handler itself like in this example:

class Operation1Handler implements OperationHandlerInterface
{
    public static function supports(OperationInterface $operation, Request $request): bool
    {
        return $operation->getApiResource()->getEntity() === Logic1::class 
                     && $operation->getKey() === 'operation1';
    }

    /**
     * @inheritDoc
     * @throws \Exception
     */
    public function handle(OperationInterface $operation, Request $request, array $route, ?ResponseInterface &$response)
    {
        // logic here
        // ...

        return [
            'result' => 'success'
        ];
    }
}

class Operation2Handler implements OperationHandlerInterface
{
    public static function supports(OperationInterface $operation, Request $request): bool
    {
        return $operation->getApiResource()->getEntity() === Logic1::class 
                     && $operation->getKey() === 'operation2';
    }

    /**
     * @inheritDoc
     * @throws \Exception
     */
    public function handle(OperationInterface $operation, Request $request, array $route, ?ResponseInterface &$response)
    {
        // logic here
        // ...

        return [
            'result' => 'success'
        ];
    }
}

[Moongazer]

That's amazing! It was quite difficult to understand whats going on with this new OperationHandler feature and how to deal with it, but so far it's working great I would say. At least I didn't run into any issue, so from my side this can be merged. Some documentation for the release would be appreciated for sure ;-)

But I've to say that this feature seems adding a lot of code, and I don't have any overview what is new, what has changed to the current version or how to test all the new functions. So, no guaranties.

Edit 1: Maybe there is a problem, but not sure. I tried to use a custom repository, which extends the CommonRepository (usecase is the example above: I want to use SUM/AVG with createQuery()). But it seems I can not overwrite the getRepositoryForOperation() to return my own repository:

Fatal error: Declaration of
  V\MyExt\OperationHandler\StatisticOperationHandler::getRepositoryForOperation(SourceBroker\T3api\Domain\Model\OperationInterface $operation): V\MyExt\Domain\Repository\StatisticRepository
  must be compatible with
  SourceBroker\T3api\OperationHandler\AbstractOperationHandler::getRepositoryForOperation(SourceBroker\T3api\Domain\Model\OperationInterface $operation): SourceBroker\T3api\Domain\Repository\CommonRepository
  in /var/www/html/packages/my_ext/Classes/OperationHandler/StatisticOperationHandler.php on line 20

The code:

// StatisticOperationHandler.php
class StatisticOperationHandler extends \SourceBroker\T3api\OperationHandler\AbstractOperationHandler {
    public function handle(...) {
        $repository = $this->getRepositoryForOperation($operation);
        $result = $repository->myCustomGet();
    }

    // overwriting the method and changing the return type 
    // maybe its better to check against a repository interface here?
    protected function getRepositoryForOperation(OperationInterface $operation): \V\MyExt\Domain\Repository\StatisticRepository {
        return \V\MyExt\Domain\Repository\StatisticRepository::getInstanceForOperation($operation);
    }
}

// StatisticRepository.php
class StatisticRepository extends \SourceBroker\T3api\Domain\Repository\CommonRepository {
  public function myCustomGet() {
    $query = $this->createQuery();
    return $query->statement('SELECT SUM(uid) AS mySum')->execute(TRUE);
  }
}

Edit 2: I tried the solution to check against an interface (ApiRepositoryInterface). The solution is pretty simple and would allow us to extend the CommonRepository to customize it way better than signal-slots would do. The following changes have to be made:

// EDIT CommonRepository.php
class CommonRepository implements ApiRepositoryInterface {
    public static function getInstanceForOperation(OperationInterface $operation): ApiRepositoryInterface { ... }

    public static function getInstanceForEntity(string $entity): ApiRepositoryInterface {
...
        $repository = $objectManager->get(static::class); // change self:: to static:: here, to use PHPs late-static-binding
...
    }
}

// EDIT AbstractOperationHandler.php
use \SourceBroker\T3api\Domain\Repository\ApiRepositoryInterface;
    protected function getRepositoryForOperation(OperationInterface $operation): ApiRepositoryInterface { ... }


// ADD ApiRepositoryInterface.php
namespace SourceBroker\T3api\Domain\Repository;
interface ApiRepositoryInterface { ... } 

With these changes, we could make the above code example for StatisticOperationHandler (Edit 1) work:

// StatisticOperationHandler.php
class StatisticOperationHandler extends \SourceBroker\T3api\OperationHandler\AbstractOperationHandler {

    // overwriting this method to return the custom repository works now
    protected function getRepositoryForOperation(OperationInterface $operation): \SourceBroker\T3api\Domain\Repository\ApiRepositoryInterface {
        return StatisticRepository::getInstanceForOperation($operation);
    }
}