[4.0] Sync app setup

[laoneo]

Summary of Changes

With the introduction of the CMSApplicationInterface in #16499 and the adjustments of the cli apps in #16540, this is the next step to harmonize the front controllers. The installation, site, administrator and all cli front controllers do have now the same way of set up and app access. All are loading the container init script, modifying the container and getting the app out of it.

JFactory::getApplication cleanup

Now JFactory::getApplication(); doesn't take any arguments anymore and will return always the global application object which must be set by the front controller during the set up phase. The problem on that part in J3 is that the code

$app = JFactory::getApplication('site');
$app = JFactory::getApplication('administrator');
echo $app->getName();
// Returns site and not administrator

will always return the site app, despite the administrator app is requested. This can be done now trough JFactory::getApplication()->getContainer()->get('SiteApplication'); which will return a site application even on the back end.

Mockable DI container

The DI container should be fetched trough the app as well, to have only one way to access it. It is possible now to mock it properly. A first step is done by creating the required functions in the test base classes. In a next step, the container needs to be set up in the appropriate test classes.

Testing Instructions

Browse around in the front and back end.

Expected result

All should work as expected.

Actual result

All is working as expected.

Documentation Changes Required

The changes in JFactory::getApplication() do need to be documented.

[wilsonge]

If you are setting factory instances in tests you need to save and restore the factory state in setUp/tearDown methods otherwise you 'contaminate' other tests (see

joomla-cms/tests/unit/suites/libraries/joomla/document/image/JDocumentImageTest.php

Lines 24 to 44 in 16d5a29

	protected function setUp()
	{
	parent::setUp();
	$this->saveFactoryState();
	JFactory::$application = $this->getMockWeb();
	$this->object = new JDocumentImage;
	}
	/**
	* Tears down the fixture, for example, closes a network connection.
	* This method is called after a test is executed.
	*/
	protected function tearDown()
	{
	$this->restoreFactoryState();
	parent::tearDown();
	}

for example)

[laoneo]

If you can come up with an approach that makes the container accessible

At least I would make it available in another class like \Joomla\CMS\Container\ContainerFactory which is deprecated and contains the container set up code and getContainer.

[mbabker]

That part's just aesthetics. What's the real difference between being in the centralized factory and it being a random class elsewhere? It's still going to be global singleton and static methods.

[laoneo]

I would like to get rid of JFactory, so adding more stuff to it would be a wrong signal. Having it in a new class would make it more clear. We can even call it InternalContainerFactory to make it cristal clear that it is only a transition class. But this can be done on a later point if required.
I did your reccomendations, so @wilsonge what do you think, ready to merge or still some concerns?

[laoneo]

Closing this one in favor of smaller pr's. Guess we stick with JFactory::getContainer()so there is no need to have an effort to move it into it's own file.