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();
 // 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();
 // 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
 }
 
 | 
  
6. Managed object classes
You can tell LAM what object classes are managed by your module.
LAM will then check the spelling of the objectClass attributes and
correct it automatically. This is useful if other applications (e.g.
smbldap-tools) also create accounts and the spelling is differnt.
Example:
The 
ieee802Device module
manages one object class.
  
    
      | /** * Returns meta data that is interpreted by parent
class
 *
 * @return array array with meta data
 */
 function
get_metaData() {
 $return = array();
 // managed object classes
 $return['objectClasses'] = array('ieee802Device');
 return $return;
 }
 
 | 
  
7. Known LDAP aliases
LDAP attributes can have several names (e.g. "cn" and "commonName" are
the same). If you manage such attributes then tell LAM about the alias
names.
LAM will then convert all alias names to the given attribute names
automatically.
Example:
The 
posixGroup module manages
the "cn" attribute. This attribute is also known under the alias
"commonName".
This way the module will never see attributes called "commonName"
because LAM renames them as soon as the LDAP entry is loaded.
  
    
      | /** * Returns meta data that is interpreted by parent
class
 *
 * @return array array with meta data
 */
 function
get_metaData() {
 $return = array();
 // LDAP aliases
 $return['LDAPaliases'] = array('commonName' =>
'cn');
 return $return;
 }
 
 |