get_dependenciesfor retrieving a list of dependencies from a given handler
get_missing_dependenciesfor retrieving a list of missing dependencies from a given handler
are_dependencies_fulfilledfor 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.
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_dependencieson a checker will return a list of unfulfilled dependencies and calling
are_dependencies_fulfilledwill return a simple boolean value answering the question.
Continuing with the handlers, the module comes pre-packaged with 2 handlers. The so-called single-checker handler and the so-called multi-checker handler. 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.
The dependencies service comes with two traits that try to automagically set things up for you. For example, the
InitializeDependenciesHandlersTraittrait lets you define a protected
get_dependencies_handlersmethod inside your class and its output will be automagically registered with the dependencies service on initialization.
Last but not least, the
SetupDependenciesAdminNoticesTraittrait goes a step further and will automagically register appropriate admin notices for dependency handlers that influence the activation state of an instance.