1. Account types
LAM currently provides three account types:
users, groups, hosts
A module can manage one or more account types.
The types are specified with
can_manage()
or
meta['account_types'].
Example:
Our
ieee802Device
module will be used only for host accounts.
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// manages host accounts
$return["account_types"] = array("host");
return $return;
}
|
2. Base modules
In LDAP every entry needs exactly one
structural
object class. Therefore all modules which provide a
structural object class are marked
as
base module.
This is done with
is_base_module()
or
meta['is_base'].
Example:
The
inetOrgPerson
module manages the structural object class "inetOrgPerson" and
therefore is a
base module.
If your module is not a base module you can skip the meta data for
this, default is
false.
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// base module
$return["is_base"] = true;
return $return;
}
|
3. Alias name
The module name is very limited, therefore every module has an
alias name. This
alias name has no limitations and
can be translated. It may contain special characters but make sure that
it does not contain HTML special characters like "<".
The
alias name can be the
same for all managed
account types
or differ for each type.
The
alias name is specified
with
get_alias()
or
meta['alias'].
Example:
Our
ieee802Device
module will get the alias MAC address.
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// manages host accounts
$return["account_types"] = array("host");
// alias name
$return["alias"] = _("MAC address");
return $return;
}
|
4. Dependencies
Modules can depend on eachother. This is useful if you need to access
attributes from other modules or the managed object classes of your
module are not structural.
The dependencies are specified with
get_dependencies()
or
meta['dependencies'].
Example:
Our
ieee802Device
module depends on the account module (because it is the only structural
module at this time).
/**
* Returns meta data that is interpreted by parent
class
*
* @return array array with meta data
*/
function
get_metaData() {
$return = array();
// manages host accounts
$return["account_types"] = array("host");
// alias name
$return["alias"] = _("MAC
address");
// module dependencies
$return['dependencies'] = array('depends' =>
array('account'), 'conflicts' => array());
return $return;
}
|
5. Messages
There are many situations where you will display messages to the user.
The modules should define such messages at a common place to make it
easier to modify them without searching the complete file.
The
baseModule offers the $
messages variable for this. It
should be filled by a function called
load_Messages().
The
baseModule will
automatically check if you have implemented this function and call it
at construction time.
Example:
Now let our
ieee802Device
module define a message.
/**
* This function fills the error message array with
messages
*/
function load_Messages() {
$this->messages['mac'][0] =
array('ERROR', 'MAC address is invalid!'); // third array value
is set dynamically
}
|