Aller au contenu

My Simple OLM

Présentation

OLM signifie Object Ldap Mapping

msolm est un générateur de classes php sur le même principe que msorm, mais pour des bases ldap

À partir d'un fichier xml qui décrit un ou plusieurs type d'entrées ldap, msolm génère un ensemble de classe php qui représentent ces entrées. Ce modèle objet php peut être copié dans un projet et est utilisable tel quel, sans qu'aucun autre outil ne soit necessaire.

Attention

Les classes générées par msolm utilisent la classe MLdap de mlib (mlib\net\ldap\MLdap).

Le modèle généré peut être augmenté avec des méthodes supplémentaires que l'on peut écrire.

L'utlisation du modèle est très facile et rend le code des applications très lisible

msolm est organisé comme suit :

msolm/
  ├── msolm.php
  ├── generators/
  │   ...
  │   ...
  └── projects/
        ├── myproject_1/
        │    └── description.xml
        └── myproject_2/
             └── description.xml

Pour un projet donné, on doit donc créer un fichier description.xml (voir ici) et lancer en ligne de commande (le fichier msolm.php soit avoir les droits d'exécution):

$ ./msolm.php -g -p myproject

Cette commande est la plus basique. Elle va prendre le fichier description.xml qui se trouve dans le sous-dossier myproject/ du dossier projects/, et créer au même niveau, un dossier model/ qui contient l'ensemble des fichiers php générés.

Il existe plusieurs options. Notamment :

  • -g (ou --generate)
  • -o (ou --output) : permet de spécifier un autre dossier de destination que le sous-dossier model/
  • -u (ou --update) : permet de ne pas écraser le code additionnel qui aurait été écrit
  • -h (ou -? ou --help) : affiche une aide qui résume toutes les options

Un exemple

Le fichier description.xml

Exemple :

<?xml version="1.0" encoding="UTF-8"?>

<ldap host="ldap.my-corp.org" port="389" bind_dn="cn=manager,dc=my-corp,dc=org" bind_password="" phpNamespace="ldapsample">    
    <object ou="ou=people,dc=my-corp,dc=org" filter="" phpObjectName="Person">
        <attribute name="uid" rdn="true" phpAttributeName="login" />
        <attribute name="sn" phpAttributeName="name" />
        <attribute name="givenName" phpAttributeName="firstname" />
        <attribute name="displayName" />
        <attribute name="mail" />
        <attribute name="otherMails" multi="true" phpAttributeName="mailAlias" phpAttributePFName="mailAliases"/>
    </object>
</ldap>

Ce qui est généré

model/
└── ldapsample
    ├── Person.php
    ├── PersonManager.php
    ├── core
    │   ├── LdapConnectionProvider.php
    │   ├── MSOLM.php
    │   ├── Person.conf.php
    │   ├── PersonCore.php
    │   ├── PersonManagerCore.php
    │   └── __ldap_params.conf.php
    └── exceptions
        ├── LdapConnectionProviderException.php
        ├── PersonException.php
        └── PersonManagerException.php
  • Chaque "object" défini dans le fichier xml donne deux classes
  • Pour chaque object, on définit l'attribut phpObjectName qui sera le nom de la classe
    • on peut aussi définir l'attribut phpObjectPFName si le pluriel n'est pas formé en ajoutant simplement un "s". 'PF' est pour 'plural form'. Cette forme est utilisée pour générer le nom du manager.
  • Pour chaque attribut, on peut définir un phpAttributeName (et événtuellement un phpAttributePFName si multi-valué) si on veut que l'attribut de la classe php soit nommé différement de l'attribut ldap. Cela permet une meilleure abstraction.

Important

Dans le dossier core/, on voit qu'en plus des deux classes ObjectCore et ObjectManagerCore, il existe un trosième fichier Object.conf.php
Ce fichier fichier définit le mapping des noms d'attributs.
Par défaut il contient ce qui est indiqué dans le fichier xml.
Mais dans le développement d'appications interfacées avec un annuaire ldap, la plupart du temps on utlilise un annuaire existant, pour lequel on a pas choisi les schemas et le nom des attributs (contrairement aux bases de données où la conception de la base fait partie du développement de l'application). C'est pourquoi on offre ici la possibilité de modifier ces noms d'attributs dans un fichier de configuration séparé. Certains attributs peuvent même être laisssés vide si l'annuaire ne dispose pas de l'information
Exemple

<?php
$ldap_base = "ou=people,dc=univ-perp,dc=fr";
$ldap_filter = "";
$ldap_attributes_mapping = array(
        "login" => "uid",  
        "name" => "sn", 
        "firstname" => "givenName", 
        "displayName" => "displayName", 
        "mail" => "mail", 
        "mailAliases" => "otherMails");
?>

Comment s'utilise ce modèle ?

Le principe est toujours le même, mais les classes générées contiennent un code et des attributs qui dépendent vraiment du fichier xml de définition.

Exemple :

$persons_manager = ldapsample\PersonsManager::getInstance();

$person = $persons_manager->get('aPersonLogin'));

echo $person->getLogin()." : "$person->getDisplayName().PHP_EOL;
echo "    ".$person->getMail().PHP_EOL;
foreach($person->getMailAliases() as $mailAlias){
    echo "    ".$mailAlias.PHP_EOL;
}

$person->addMailAlias('ceo@mycorp.org');
$persons_manager->update($person);

Dans l'exemple ci-dessus on voit que pour chaque "objet" défini en xml, on a deux classes php : une classe "Object" et une classe "ObjectsManager".

  • La première représente des objets avec leurs attributs (avec leurs getteurs et setteurs)
  • La deuxième est une classe qui permet de gérer ces objets : obtenir un ou plusieurs objets, en vérifier l'existence, en ajouter, en supprimer ou les mettre à jour.

Ces deux classes héritent de leurs équivalents "core" qui contiennent tous les attributs et méthodes fournies par défaut.

Ces deux classes peuvent donc tout à fait être enrichies d'autres attributs ou méthodes qui vous manqueraient.

À la différence de msorm, msolm ne gère pas les relations qui pourraient exister entre les objets (valeurs d'un attributs d'un objet Person et appartenance à un autre objet Group par exemple).