Project

General

Profile

Actions

Bug #70873

closed

Fix inconsistency of the calling order of Container::injectDependencies() and AbstractEntity::initializeObject()

Added by Klaus Bitto over 8 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2015-10-20
Due date:
% Done:

0%

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

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. :)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #66482: Extbase persistence layer fails to create empty objects in PHP 5.6.Closed2015-04-19

Actions
Actions #1

Updated by Helmut Hummel over 8 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?

Actions #2

Updated by Mathias Schreiber over 8 years ago

  • Target version deleted (next-patchlevel)
Actions #3

Updated by Klaus Bitto over 8 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.

Actions #4

Updated by Helmut Hummel about 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.

Actions

Also available in: Atom PDF