Bug #70873
closed
Fix inconsistency of the calling order of Container::injectDependencies() and AbstractEntity::initializeObject()
0%
Description
This is born out of the discussion at https://review.typo3.org/#/c/40522/ (https://forge.typo3.org/issues/66482)
Container::getEmptyObject() calls first initializeObject(), then injectDependencies().
Container::getInstanceInternal() calls first injectDependencies(), then initializeObject().
From a software design standpoint, it would definitely make much more sense to change __wakeup() and call initializeObject() only after injectDependencies() whereever it applies. Otherwise, initializeObject() as an API construct is much less useful. Many scenarios would require e.g. an injected objectManager/configurationManager to setup the object for use. There is no other auto-called method for initializing after dependencies have become available. This seems wrong to me. :)
Updated by Helmut Hummel about 9 years ago
- Status changed from New to Needs Feedback
This is fixed in master and cannot be fixed in 6.2 without loosing backwards compatibility.
This btw. only is an issue when using dependency injection in entities and value objects (persistable objects), which are the only objects created from persistence. Using DI for entities and value objects is an edge case imho, which cannot be considered best practice.
I would like to close this. If you really need consistency in this area, switch to 7LTS or write workaround code in your entities.
Am I missing something?
Updated by Mathias Schreiber about 9 years ago
- Target version deleted (
next-patchlevel)
Updated by Klaus Bitto almost 9 years ago
Hi Helmut,
pity to see that https://forge.typo3.org/projects/typo3cms-core/repository/revisions/9faa965d27ab9f6823d2ec270f00b7ffd940c1bd/diff/typo3/sysext/extbase/Classes/Object/Container/Container.php left this unfixed, but I guess your reasoning makes sense from a stability standpoint.
In that sense I think you can probably close this ticket. Workarounds will need to be written.
However: Is there any documentation of this inconsistency anywhere? It might make sense to add a warning to the DI and/or Entity lifecycle documentation.
Updated by Helmut Hummel over 8 years ago
- Status changed from Needs Feedback to Rejected
Hi!
Klaus Bitto wrote:
However: Is there any documentation of this inconsistency anywhere? It might make sense to add a warning to the DI and/or Entity lifecycle documentation.
It is a Bug which we fixed in our latest release. No there is no documentation about that, besides this ticket. I also cannot imagine a good place to document this (especially because of lacking recent docs about Extbase DI/ Object Lifecycle)
I'll close the ticket now.