The main purposes of standard module interfaces are:
The standard module interfaces provide listing of object methods, attributes and configuration that should be used for objects that are named by reserved names (e.g. "Mapper", "Site", "Session" and others).
This means that if you load an object called "Mapper" anywhere in your application you will know that it will have method mapRequest()
. Even if you use a different implementation of the object written by different programmers and using different algorithms.
Lets say you use a Session module from the default modules pack. This session module uses the PHP $_SESSION
variable and default session handling settings. Now lets say you don't like this implementation. Maybe you feel it is insecure because it stores session files in plain text on a server shared between many users. Maybe you need to give your application users possibility to set session timeout time through web interface. There may be a number of reasons.
In such situation you may not be able to solve the problem by altering PHP session configuration settings in php.ini file. What you should do is write your own session module (or find an already written one) that stores session data in SQL database or in some alternative storage system.
The fun part is... that if you programmed your application keeping to the standard module interface, you won't have to rewrite a line of your code. You may just configure your application to use another class when loading object named "Session".
Your code:
$session = &loadObject('Session'); $session->assign('myVar', 'myVal');
will work just as it always worked.