Container DRY

[BernhardPosselt]

To make it easier for newcomers and more DRY for app authors it would be nice if we could let the container figure out the dependencies by itself :)

$c->registerService('PageController', $callback);
$c->query('PageController');

This will still work and will help us handle the edge cases such as register callbacks for interfaces and parameters.

Now let's enhance the query() method to do the following if no callback/parameter is registered for a key:

• Does a class called PageController exist? No
• Does a class called \OCA\MyApp\Controller\PageController exist? Yes (This is the default. The first lookup for PageController is done in the routing system to keep backwards compability)
• What parameters does it take in its constructor? $AppName, \OCP\IRequest $request, \OCA\MyApp\Service $service
• Is there a type for $AppName? No
  • Is there a service/parameter registered for AppName? Yes -> use that
• Is there a type for $request? Yes \OCP\IRequest
  • Is it an interface? Yes -> damn we cant instantiate it, fail. Now this needs to be registered with the traditional callback style like $c->registerService('\OCP\IRequest', $callback). Ideally we've got support for all those interfaces in the base container
• Is there a type for $service? Yes \OCA\MyApp\Service
  • Is it an interface? No -> great we can instantiate it. Use reflection to find its parameters etc
• All parameters for PageController are assembled so we can construct PageController and return it

Ok great. This allows in 99% of all cases to get rid of appinfo/application.php. When do you still need it?

• You are using custom interfaces in your app as type parameters (unlikely)
• You are injecting strings/ints/arrays/callbacks into your constructor (kinda likely, but you can easily create a pure POPO classes that hold these parameters as public attributes, like \OCA\News\Config->SomeString)

What do we gain by this? A smoother learning curve and more DRY. By default you dont have to deal with anything, you just use the correct types in your controllers and other classes and everything works out of the box. Should you still need an exception, you can add the appinfo/application.php and you need to know exactly as much as now. Downsides? You have to supply type hints (you should do that anyways) and it might be obscure why __construct($AppName) works but __construct($appName) doesnt.

PS: What about routing?

Well in appinfo/routes.php we've got the following atm:

$application = new Application();
$application->registerRoutes($this, ['routes' => [
   ['name' => 'page#index', 'url' => '/', 'verb' => 'GET'],
   ['name' => 'page#do_echo', 'url' => '/echo', 'verb' => 'POST'],
]]);

What if we could this instead?:

return  ['routes' => [
    ['name' => 'page#index', 'url' => '/', 'verb' => 'GET'],
    ['name' => 'page#do_echo', 'url' => '/echo', 'verb' => 'POST'],
]];

The router could check if an array is being returned. If an array is being returned, you can instantiate a container with the current app name (it is the first constructor parameter! https://github.com/owncloud/core/blob/master/lib/public/appframework/app.php#L43) and call the registerRoutes method in it with the returned array.

What about cron? Just create a new Application with your appname and you're done :)

@georgehrke @DeepDiver1975 @butonic @PVince81 @MorrisJobke @nickvergessen @jbtbnl

[BernhardPosselt]

Both PRs open :)

[BernhardPosselt]

I've morged it into one PR since it is easier for testing. Please review

[MorrisJobke]

Sounds nice :)

[MorrisJobke]

#12830 is merged