Bug #70873
closed
Fix inconsistency of the calling order of Container::injectDependencies() and AbstractEntity::initializeObject()
Added by Klaus Bitto about 9 years ago.
Updated over 8 years ago.
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. :)
- 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?
- Target version deleted (
next-patchlevel)
- 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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by