Project

General

Profile

Actions
Copy link

Bug #77828

closed

Inversion of Control is not working in controller action arguments

Added by Dennis Römmich about 8 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2016-09-03
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
5.6
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

If you register an Implementation like extbase does in typo3/sysext/extbase/ext_localconf.php:9 it won't be considered if the given interface ist passed as an action controller argument.

Example:
1. Register an implementation in your ext_localconf.php

/** @var $extbaseObjectContainer \TYPO3\CMS\Extbase\Object\Container\Container */
$extbaseObjectContainer = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Extbase\Object\Container\Container::class);
$extbaseObjectContainer->registerImplementation(\MyVendor\MyExtension\MyInterface::class, \MyVendor\MyExtension\Domain\Model\MyClass::class);

2. Create a simple Action in your ActionController with passig MyInterface as TypeHint:

    /**
     * showAction
     *
     * @param \MyVendor\MyExtension\MyInterface $myClass
     * @return void
     */
    public function showAction(\MyVendor\MyExtension\MyInterface $myClass)
    {
        //do some stuff
    }

It will lead to an Exception:

#1297759968: Exception while property mapping at property path "": No converter found which can be used to convert from "string" to "\MyVendor\MyExtension\MyInterface".

Actions
Copy link
 #1

Updated by Gerrit Code Review about 8 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/49827

Actions
Copy link
 #2

Updated by Gerrit Code Review about 8 years ago

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/49834

Actions
Copy link
 #3

Updated by Gerrit Code Review about 8 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/49827

Actions
Copy link
 #4

Updated by Gerrit Code Review about 8 years ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/49827

Actions
Copy link
 #5

Updated by Dennis Römmich over 7 years ago

@Claus Due: Thanks for your review.
Generally i agree with you that my implementation might be the wrong place.
So do you think everbody who needs inversion of control needs to build his own TypoConverter or do you think this can be part of the TYPO3 core?

Actions
Copy link
 #6

Updated by Claus Due almost 7 years ago

So do you think everbody who needs inversion of control needs to build his own TypoConverter or do you think this can be part of the TYPO3 core?

This is one of the cases where yes, I think everyone would have to create a TypeConverter that converts from their particular interface to their desired object type. While a DelegatedTypeConverter or similar could be possible to create, its actual usefulness is limited to this particular use case and not much else. Your request is the first time I've heard anyone requesting to-interface-name-mapping in Extbase since it was created, so it isn't exactly frequent request.

There are simply too many ambiguities if this were a core feature. An interface tells you absolutely nothing about how a particular object can be created - it would have to delegate everything to whichever implementation it translates to in runtime, and this implementation could be literally anything (persisted object, DTO, service instance, singleton or not, validatable or not, array accessible, and so on with every single different type of object). So while it could perhaps make sense to allow a very select handful of interfaces which when used, clearly indicate that an object is for example a persisted domain object, I would always argue, that this adds unnecessary complexity when the obvious solution is to create a subclass of the appropriate TypeConverter you need, then change the supported target type to include your specific interface.

This would, by the way, also be necessary if for example you needed a converter that can convert from string to array or vice versa. There just are some cases where you must create a TypeConverter of your own, because the built-in ones are incapable of handling such dynamic or too low-level types.

Actions
Copy link
 #7

Updated by Christian Kuhn almost 7 years ago

  • Status changed from Under Review to Rejected

Thanks for this resumee, claus.
I think we should close this issue as rejected for now.
Dennis, please re-open, open a new issue, or contact us via slack if you think we should shed further light on this topic.

Actions
Copy link
 #8

Updated by Christian Kuhn almost 7 years ago

  • Status changed from Rejected to Closed
Actions
Copy link

Also available in: Atom PDF