Services

Services are commonly used libraries which provide functionality on a near global scale to a given Web application or Web site. As such constantly binding such libraries as components becomes tiresome and so a much simpler and easier interface exists. All services can be accessed from a component or from another service (even from itself) via the getService() method. This method should have been inherited by all components extending the JinnBaseComponent class and by all services which should extend the JinnBaseService class. The following illustrates how easy it is to obtain a service and to use it:

//
// Get the session manager service.
//
$sessionManager = $this->getService( 'sessionManager' );

//
// Now retrieve an instance of the current session object.
//
$session = $sessionManager->do->getCurrentSession();

For convenience sake developers may also use getLibrary() to retrieve a service. Libraries and services are generally only different by virtue of interpretation.

The textual links listed in the left navigation will take you to a description of the public API for the corresponding service. It is important to mention that the API described there should be the API adhered to when creating replacement services. Also worth mentioning is that the class names listed in the API descriptions are for the particular core implementations, and in practice may not be the class of the object obtained by a call to the getService() method. For instance the PEAR::DB database wrapper is an optional alternate databaseManager service that conforms to the API described for the databaseManager service and it's class name is PearDbManager and not the listed JinnDatabaseManager.

If you have not yet read about it, then the use of ->do may have you wondering about its purpose. The ->do resolution is necessary because by default all objects and services when retrieved are returned with a wrapper layer. This is to bypass an issue in PHP where functions and methods return copies of objects instead of a reference. This is dangerous when singleton objects are being manipulated that internally keep track of such things as session data or other such single instance data. At any rate, this technique may very well be deprecated (although compatability will be retained) with the release of PHP 5 which according to documentation will always return object references.