Ajouter un module maison : exemple entité "serveur"
De Typo3 CMS / Documentation Typo3 / Support Typo3.
Sommaire |
contexte
Je connais assez mal l'architecture des paquet debian, et pas très bien l'architecture des fichiers Altern - ce document de travail se voudrait cependant respectueux des normes - nous nous efforcerons donc de compléter / corriger les aspects normatif au fil des développements / découvertes.
Je prends l'exemple de l'entité machine - ma première expérience de module alternc - destiné à éditer la configuration d'un machine d'un réseau interne pour se brancher en http via un reverse proxy - ou lancer des opérations de déploiement d'application.
convention de nommage : Notre entité serveur sera designée ( variable, nom de fichiers php etc ..) comme "serv" en version courte ou "server(s)" en version longue
ajouter l'entrée dans le menu
La liste des entrées à charger dans le menu est stockée dans /etc/alternc/menulist.txt on y ajoute une ligne sous la forme :
menu_servers.php
todo : voir comment l'ajout de l'entrée de menu peut se faire respectueusement des autres modules chargées dans AlternC.
on prépare donc le fichier "menu_" qui va bien - on peut dupliquer un menu existant.
la table
On ajoute dans la base altern la table qui va bien - prévoir la gestion des droits / propriétaires le cas échéant ( todo )
la classe gérant l'entité
Dans le dossier classe on place un fichier m_serv.php - alternC charge automatiquement le fichier - la classe devra implémenter un certain nombre de méthode standards - j'ai d'ores et déjà identifié :
Méthodes appelées par Alternc :
- lock / unlock : verrou pour se prémunir des accès concurrents.
- alternc_quota_names : retourne la clef pour la gestion des quotas utilisateur. Le nom court semble le faire, mais bizarrement ce n'est pas le comportement par défaut ?
Normes de nommage :
- get_server_all($serv) : charge et retourne dans un tableau toutes les propriétés de l'entité en question
- enum_servers : enum_machin retourne la liste des "machin" sous forme de tableau et le stock en varibale membre de l'objet.
- add_ edit_ del_ set_: parlent d'eux mêmes
=> en général on se basera sur des exemples comme m_dom.pho ou m_mail ...
les interfaces d'édition
Reste à préparer / modifier sur la base d'un fichiers standard - les interfaces appelèes depuis les menus et leur pendant "do" traitement du formulaire :
serv_add.php serv_doadd.php
serv_edit.php serv_doedit.php
serv_del.php serv_dodel.php
Chainage des actions pour les modifications DNS
Les modifs à apporter à Bind suivent ce parcours :
- Chaque modification dans l'interface d'admin entraine la création d'enregistrements dans la base de données. (interface admin -> bd)
- Toutes les 5 minutes, le cron fait tourner le script /usr/lib/alternc/update_domains.sh. Celui-ci récupère les nouveaux enregistrements en BD et les transforme en fichiers de conf pour Bind. Les fichiers sont rangés ensuite dans /var/alternc/bind/. Ce même script recharge bind via la commande 'rndc reload' et 'rndc reload $zone'.
les quotas
Si la classe implémente les méthodes qui vont bien on voit apparaître notre entité serveur dans le panneau des quotas standard d'AlternC
localisation
toutes les chaînes seront renvoyées en anglais via :
<?php __(" my string "); ?>
Explications : les fonctions _() et __() (préférée) font appel à GETTEXT pour permettre l'internationalisation. Les traductions se trouvent dans /var/alternc/bureau/locales/<codeLangue>_<codePays>/LC_MESSAGES/
Il y a deux fichiers : - manual.po (messages d'erreur) - messages.po (autres traductions)
Après avoir édité ces fichiers, il faut appeler gettext à la rescousse via le Makefile :
$ cd /var/alternc/bureau/locales $ make
ceci assemblera les deux fichiers en un alternc.mo qui contiendra toutes les traductions pour alternc.
