Wiki - 1 output

Organisation générale

Un projet it.rocks est stocké sur disque dur en respectant ces principes :

• la racine contient les fichiers de configuration généraux du projet final composer.json, le fichier de réglages locaux loc.php et les mots de passes pwd.php,

• le projet représentant votre logiciel, et tous les logiciels dont il hérite pour utiliser de leurs composants, sont stockés à partir de la racine dans un sous-dossier author/application. Vous avez donc un dossier par auteur ou éditeur du logiciel, et un sous-dossier par logiciel. Par exemple itrocks/framework est le framework maintenu par la communauté it.rocks.

• le dossier vendor contient les modules logiciels développés par des tiers hors Framework it.rocks qu’utilisent it.rocks et les différentes couches logicielles que vous utilisez. Idéalement, l’architecture de nommage pour ces modules tiers doit respecter la convention vendor/author/module. Ils peuvent être maintenu par un fichier de configuration composer.json installé dans la racine pour en faciliter l’installation.

• le dossier cache, initialement vide, contient les caches de scripts php générés par le framework pour le bon fonctionnement de l’AOP, de la composition de classes, getters, setters et autres fonctionnements internes du framework.

Organisation dans un dossier logiciel

Classe métier (modèle)

Le concept général choisi par it.rocks est de nommer ses classes métier (modèle) en fonction de l’auteur, du nom du logiciel, du nom du module et sous-module (etc) où elle est logée, et du nom métier qu’elle représente.

Par exemple dans un logiciel de gestion commerciale qui s’appellerait Management et édité par la société Author, gérant d’un côté ventes et achats, on pourra nommer la classe commandes de ventes comme suit:

Author\Management\Sales\Order

On parle donc toujours de la commande du module des ventes du logiciel Management édité par Author.

• elle doit commencer par le nom de l’auteur ou de l’éditeur,
• vient ensuite le nom du logiciel ou module autonome,
• peuvent venir ensuite un ou plusieurs sous-modules,
• le nom de la classe représente son sens métier, dans le contexte du sous-module et donc sans répéter les mots clés identifiant modules et sous-modules.

• soit le nom du dossier où est stocké la classe correspond à son namespace, sans le nom de la classe final, tout en minuscules. Le nom de fichier est alors le nom court (sans namespace) de la classe, incluant les majustcules.
  Pour notre classe Author\Management\Sales\Order, le fichier correspondant est author/management/sales/Order.php.
  Ce cas est à employer uniquement si le module commande de ventes est constitué uniquement de la classe métier Order, et qu’aucun autre fichier ne dépend de son fonctionnement, ne justifiant pas l’utilisation d’un sous-dossier qui par définition est prévu pour accueillir plusieurs fichiers.
• soit le nom du dossier est le nom complet de la classe, incluant namespace et nom court, tout en minuscules. Le nom du fichier qui contient le code source de la table est toujours le nom court (sans namespace) de la classe, incluant les majuscules.
  Pour notre classe Author\Management\Sales\Order, le fichier correspondant est author/management/sales/order/Order.php.
  Le sous-dossier contiendra alors les autres éléments du module commande de ventes : vue, contrôleur, template HTML, javascript, etc. Ces autres composants devront être sous namespace Author\Management\Sales\Order, seule la classe Order sera sous namespace Author\Management\Sales, pour ces raisons :
  • pour assurer la compatiblité de nommage de la classe si dans un premier temps elle n’était pas en sous-dossier car seule, et qu’ensuite en modifiant le logiciel vous avez choisir de la stocker dans le sous-dossier,
  • en tant que concept métier qui a donné son nom au module,
  • pour éviter toute répétition dans le nom complet de la classe : il est plus léger de l’appeler Author\Management\Sales\Order que Author\Management\Sales\Order\Order.

Classe contrôleur

Cet article reste à compléter