Dependencies Service
Last updated
Was this helpful?
Last updated
Was this helpful?
The dependencies service is with no implemented . The purpose of this service is to provide a unified way of checking whether dependencies are fulfilled or not. It provides the following public methods:
get_dependencies for retrieving a list of dependencies from a given handler
get_missing_dependencies for retrieving a list of missing dependencies from a given handler
are_dependencies_fulfilled for retrieving a list of boolean values determining whether the dependencies of a given handler are fulfilled or not
You must be used by now to the fact that every service has its quirks. In the case of the dependencies service, the quirk is that it has no default handlers because each handler is supposed to be tied to a particular class instance.
Dependency handlers all implement the and are in essence little more than containers for dependency checkers. Dependency checkers, in turn, all implement the interface.
Let's start from the bottom-up. The utilities module comes pre-packaged with 4 dependencies checker. They are and, in no particular order, provide checking for the following types of dependencies: , , , and .
At its core, a checker accepts a list of dependencies (each checker might have a different format) and knows how to check whether said dependencies are fulfilled or not. Calling get_missing_dependencies on a checker will return a list of unfulfilled dependencies and calling are_dependencies_fulfilled will return a simple boolean value answering the question.
Continuing with the handlers, the module comes pre-packaged with 2 handlers. The so-called and the so-called . As their names suggest, the former can store one checker whereas the latter can store multiple checkers. This is a necessary abstraction for supporting the services model.
The difference between the two is that most functions of the single-checker handler will return an array whereas the same functions of the multi-checker handler will return a matrix.
It might come as a surprise to find out the the method are_dependencies_fulfilled of the single-checker handler returns an array with a single entry instead of a simple boolean value. This is done for consistency with the multi-checker handler.
The dependencies service comes with two traits that try to automagically set things up for you. For example, the trait lets you define a protected get_dependencies_handlers method inside your class and its output will be automagically registered with the dependencies service on initialization.
Similarly contains two traits that let you automagically turn an instance inactive or disabled based on registered dependencies handlers.
Last but not least, the trait goes a step further and will automagically register appropriate admin notices for dependency handlers that influence the activation state of an instance.
Watch out for the SetupDependenciesAdminNoticesTrait trait! It uses the SetupableInactiveTrait which will cause your instance to setup even if inactive. You need to design your code around this.