This will allow constructing API modules that need services.
This overhauls some of the internals of the ApiModuleManager,
but the public interface remains unchanged.
The $class parameter of addModule, (now called $spec)
also allows passing an array with the spec of the module.
Note that this spec requires the attribute 'class' to be present,
even when 'factory' is specified. This is the same as before,
where $class was always required.
In a perfect DI world ObjectFactory would be injected into
ApiMain::__construct and ApiMain would pass that to its instance
of ApiModuleManager, but that is currently not possible, so for now
it is injected in ApiModuleManager by having ApiMain::__construct
call the service locator.
Bug: T222388
Change-Id: Iee04afc27283547dd68d6db93f44ac2e0ebf1258
In cases where an extension has multiple API modules that
have the same exact factory requirements, it would let them
use the same factory function and check with the module manager
what the class name to construct should be. This is already possible
using getNamesWithClasses, but this makes it much more
straightforward.
Change-Id: I889e3e6f15907896a8df376913125d903debe984
- Added newline at end of files
- Added/Removed spaces around comma, parentheses and negation
- Added space after function word
Change-Id: I2dd338153aeb5f07702ba015945e95c7d0ae673b
This enables factory functions to be registered for API modules,
in addition to the module class itself. This allows modules to
use proper dependency injection via the modules constructor.
Example:
$wgAPIModules['foo'] = array(
'class' => 'ApiFoo',
'factory' => function( $main, $action ) { ... }
)
Change-Id: Ieb85493a7765f466317f5fa74b0b0e262220deab
