Imaginer vouloir lister dynamiquement les modules présents dans votre application. Mais pourquoi?
Par exemple pour faire un menu dynamique à votre backend et ainsi éviter de retoucher au layout sans cesse!
Je reprend la technique de funstaff.ch avec la class sfFinder disponible sous symfony.
Quelques liens:
- L’API officiel de la classe sfFinder
- L’API avec un design simpliste de la classe sfFinder
- Le code source de la classe sfFinder
La classe sfFinder
C’est (comme son nom l’indique) une classe qui permet de faire des recherches!!! WAOUUUU mais encore? Elle permet de faire des recherches sur des fichiers ou/et des répertoires.
Comment manipuler cette classe ?
// On crée l'objet sfFinder en spécifiant le type de la recherche
// soit des fichiers (file), soit des répertoires (dir) ou tous (any)
$finder = sfFinder::type('file');
// On peut préciser des filtres
$finder->name('*.php');
// Et enfin lancer la recherche avec in($dir_de_recherche)
$files = $finder->in('/home/prod/mon_projet');
// Cette méthode retourne un array de fchier
// Exemple de traitement de la réponse:
foreach ($files as $file) {
$handle = fopen($file, "r");
...
}
Je reviendrai sur cette classe peut-être dans un post dédié à elle. Mais là le but est toujours de lister les modules d’une application!
Lister les modules d’une application
$modules = sfFinder::type('directory')
->relative()
->maxdepth(0)
->in(sfConfig::get('sf_app_module_dir'));
Je traduis:
- On recherche des répertoires
- On veut que le résultat de la méthode in() à la place de retourner par défaut un chemin absolu,  nous retourne un tableau de chemin relatif (c’est à dire relatif au chemin du script courant ou vous êtes!)
- On ne rentre dans aucun des dossiers trouvés
- On lance la recherche dans le répertoire des modules de symfony
Voici l’architecture d’une application symfony:
|VOTRE APPLICATION (frontend, backend, etc…)
|–config
|–lib
|–module (le dossier que l’on parcours pendant la recherche)
|—-module1 (on ne rentre pas dans module1,2 etc…)
|—-module2
|—-etc…
|–templates
En retournant les chemins relatifs et non absolu, et étant placé dans le dossier /module/, le tableau de fichier renverra simplement le nom des modules :)
Bon dév’ :D
Pratique oui.. Mais pour générer des menus automatiquement on perd 3 choses importantes à mon avis : première chose, c’est bête mais le nom du module ne peut pas forcément faire un joli menu (par exemple avec la perte d’accents etc.), deuxièmement on perd toute personnalisation du menu et enfin la plus grosses perte, les credentials… C’est bon quand tu n’as qu’un utilisateur ou qu’ils ont tous les mêmes droits.. Mais si tu commences à avoir une gestion fine des droits, ça la fou mal de mettre des actions possible pour l’utilisateur et quand il clique il arrive sur une page qui lui dit qu’il n’a pas les bons credentials…
D’accord se taper un menu à la main est du coup beaucoup beaucoup plus fastidieux, mais ça reste pour moi la meilleure solution. A moins que tu t’embêtes à lire le fichier credentials, tester si ton utilisateur possède les bons droits, listez tous les fichier *Success.php dans templates pour déduire à peu prêt les actions possibles (à laquelle tu pourrais ajouter une sorte de filtre avec des actions impossible à faire directement depuis le menu…
Donc je pense que générer des menus avec cette technique est bien pour faire des menus génériques, mais quand ça doit être un peu plus customisé, c’est pas encore le top :D
Pour la perte des accents, il suffit de customiser certain module via le settings.yml de la façon suivante:
all:
.settings:
admin_theme:
auto_menu: true
remove_from_menu: [event]
replace_in_menu: [event:Evènement]
Et tu récupère ça dans ton listing.
Pour le niveau de personnalisation, j’ai seulement dit que je voulais lister les modules. C’est sûr qu’un menu plus complexe n’est pas possible, ou alors en améliorant la génération à coup de configuration YML, ce qui n’ai pas mon but!
Pour la perte des crédentials, je ne suis pas d’accord, je test suivant la config dans le crédential, si l’utilisateur peut oui ou non voir le menu avec la base sfBasicSecurityUser et les méthode concernant les credentials (hasCredentials, clearCredentials, removeCredentials, addCredentials).
Ce post ne présente qu’une astuce pour lister les différents modules d’une application, ce n’est en aucun cas une solution miracle et qui s’adapte à un développement spécifique.
Dans beaucoup de site dît “vitrine” .
Le but d’un helper/plugin comme la génération automatique de menu ne peut pas être utilisé dans le cadre de développement spécifique, mais dans la génération simple et facile d’un menu à chaque fois identique.
Pas mal pour le settings :D
Pour les credentials, je ne comprend pas trop. Comment fais-tu pour lister les credentials d’un module en particulier ?