Everything begins with the call-up of the http://localhost/sayhello URL. The HTTP request reaches the web server, which after consulting .htaccess decides that the index.php has to be processed by the PHP interpreter. In the scope of the index.php, the autoloading is initially configured and subsequently the application’s init() method is called up.
run();
ServiceManage
The ServiceManager instantiated there:
As a result of the transfer of ServiceManagerConfig, the ServiceManager is equipped with
several standard services which Zend\Mvc requires for smooth functioning. In addition the
corresponding configuration is transferred tothe ServiceManagerConfig from the previously loaded
application.config.php.
The ServiceManager is a sort of Zend_Registry with extended functions. Whereas the Zend_Registry of Version 1 could merely file existing objects under a certain key and subsequently load them again (key value storage), the ServiceManager goes several steps further.
Services and service generation
In addition to the administration of services in the form of objects, a “generator” can also be registered for a key, which generates the respective service initially when needed. To achieve this,
either classes (fully qualified, i.e., if necessary, with declaration of the namespace, which are then
on request instantiated, for example in the form
setInvokableClass( 'MyService', 'Helloworld\Service\MyService' );
or factories can be deposited.
setFactory( 'MyServiceFactory', 'Helloworld\Service\MyServiceFactory' );
In order for the ServiceManager to be able to manage the MyServiceFactory, the latter has to
implement the FactoryInterface, which requires a createService method. This method is then
called up by the ServiceManager. As light-weight implementation of a factor, a Callback function
can be directly transferred.
setFactory( 'MyServiceFactory', function($serviceManager) { // [..] } );
Alternatively, can an abstract Factory also be analogously filed, where by this is added without
Identifier; this is shown here exemplarily in a Callback variant.
addAbstractFactory( function($serviceManager) { // [..] });
In addition, so-called “Initializers” can be filed; they ensure that a service is equipped with values
or references to other objects when it is called up. “Initializers” can be so conceived that the inject
objects into a service when the respective service implements a defined interface. We will see this
in action again later. At the moment, we should only remember that they exist. All services made
available by the ServiceManager are so-called “shared services”, this means that the instance of a
service—generated when needed or already present— can also be returned at a second request of just this service instance. The instance of the service is thus reused. This is valid for all standard services defined by Framework; the only exception in this context is the EventManager. If a new service is registered, one can also prevent the reuse of instances.
setInvokableClass( 'myService', 'Helloworld\Service\MyService', false);
Standard services, Part 1
At the very beginning of request processing, the ServiceManagerConfig ensures that a number
of standard services are made available. It is important to realize that there are services in the
ServiceManager, which can in part only be used by Framework (or more exactly by its MVC
implementation), whereas some other services are also useful for the application developer, for
example in the context of a Controller. This will become clearer somewhat further along.
Invocables
The following service is made available as an “invocable”, i.e. by specifying a class, which is then
instantiated when necessary. SharedEventManager (Zend\EventManager\SharedEventManager): Allows the registration of listeners for certain events, also when the event manager required for this is not yet available. The SharedEventManager is automatically made available by a new EventManager when this is generated by the ServiceManager. Further explanations of the SharedEventManager will be found later in the book.
Factories
In the context of the ServiceManager, Factories are there to make services available, which do not
exist until the real request occurs, but rather are built by a Factory “on demand”. The following
services are made available indirectly by a factory as standard. SharedEventManager (Zend\EventManager\SharedEventManager): The EventManager can generate events and inform registered listeners about them. It can also be requested via the Zend\EventManager\EventManagerInterfacealias.
ModuleManager (Zend\Mvc\Service\ModuleManagerFactory): Administers the modules of a
ZF2 application.
Configuration
The ServiceManager is thus decisively controlled for use in the scope of request processing by
two configurations: The ServiceManagerConfig, which defines a number of standard services for
request processing, and also by the application.config.php or module-specific configurations,
respectively. In each case, the service_manager key is essential for this:
array( // [..] ),);
Below the service_manager'keys, the following keys are then possible:
services: Definition of Services with the aid of already instantiated objects.
invocables: Definition of services by declaration of a class, which is instantiated when
needed.
factories: Definition of factories, which instantiate serves.
abstract_factories: Definition of abstract factories.
aliases: Definition of aliases.
shared: Allows the explicit declaration of whether a certain service can be used a number of
times or should be re-instantiated if again required.
As soon as the ServiceManager is available, the application.config.php is, then as a whole, i.e.
also with the other non-ServiceManagerrelevant sections, itself made available as service.
setService('ApplicationConfig', $configuration);
This is important because other components, such as the ModuleManager or ViewManager, also access these services.
At the present time, the ServiceManager (equipped with diverse standard services) is thus in
readiness and, in a manner of speaking, is only waiting for the show to begin. For, up to now
not much has happened except for a few basic preparations. In fact, at this point nearly all of the
above-mentioned services do not yet exist because they have not yet been requested and are only
generated when necessary.