[TASK] Deprecate extbase ObjectManager->getEmptyObject()
ObjectManager->getEmptyObject() is only used in extbase persistence DataMapper when domain objects are "thawed": An existing DB row is fetched and a model object is created from it. From extbase PoV, a domain object lifecycle is "creation" ("own a new car"), then eventually "freezing" it in DB, "thawing" it from DB to update it's state ("washed today, it's now clean"), and eventually deletion ("brought to scrapyard, don't own it anymore"). Extbase now says that "thawing" and "creation" are two different things and thus decided that programmatically, __construct() on thawed objects should NOT be called, because, well, it's not new, just thawed! Don't assume __wakeup() is called instead, though: It's not. Extbase of course has to hop through quite some loops to violate this PHP language construct. It even needs the 3rd party dependency doctrine/instantiator to achieve suppressing __construct() call, since the previous 'unserialize hack' broke somewhere during PHP 5 times. Additionally, even though extbase Domain Model objects *should* be plain old PHP objects, they still allow inject* methods and are dependency injection aware. This is a problem when moving away from ObjectManager towards symfony DI, because symfony does not support this creative extbase view of supressing __construct() when instantiating objects. We can't get rid of this easily in extbase, though. There is no good way to deprecation-log this behavior. A feature toggle seems to be overkill - probably not too many extbase devs are aware of this implementation detail in the first place, and the impact if __construct() is properly called when an object is thawed should be relatively small: First, models are usually relatively stupid in extbase (which is good, they should be), and if they have a __construct() method at all, chances are, everything that is done there is overriden during the following mapping process anyways. We thus decided against a feature toggle for this. Instead, we *keep* the current instantiation logic in v11, just mark the code places as deprecated, configure the extension scanner to look for additional getEmptyObject() calls in extensions, and add a depreation reST file pointing out the situation and stating __construct() will be called in v12 for thawed objects. Resolves: #94377 Related: #90803 Releases: master Change-Id: Ied3da8b9d885be2f635b9bc6c66b37fc9825decc Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/69520 Tested-by:Jochen <rothjochen@gmail.com> Tested-by:
core-ci <typo3@b13.com> Tested-by:
Daniel Goerz <daniel.goerz@posteo.de> Tested-by:
Christian Kuhn <lolli@schwarzbu.ch> Reviewed-by:
Jochen <rothjochen@gmail.com> Reviewed-by:
Daniel Goerz <daniel.goerz@posteo.de> Reviewed-by:
Christian Kuhn <lolli@schwarzbu.ch>
Showing
- typo3/sysext/core/Documentation/Changelog/master/Deprecation-94377-ExtbaseObjectManager-getEmptyObject.rst 52 additions, 0 deletions...Deprecation-94377-ExtbaseObjectManager-getEmptyObject.rst
- typo3/sysext/extbase/Classes/Object/ObjectManager.php 2 additions, 0 deletionstypo3/sysext/extbase/Classes/Object/ObjectManager.php
- typo3/sysext/extbase/Classes/Persistence/Generic/Mapper/DataMapper.php 1 addition, 0 deletions...extbase/Classes/Persistence/Generic/Mapper/DataMapper.php
- typo3/sysext/install/Configuration/ExtensionScanner/Php/MethodCallMatcher.php 7 additions, 0 deletions.../Configuration/ExtensionScanner/Php/MethodCallMatcher.php
Please register or sign in to comment