Création du module
Les modules constituent le principal moyen d’étendre les fonctionnalités de NexoPOS. Ils permettent aux développeurs d’introduire de nouvelles fonctionnalités, de personnaliser des comportements existants ou d’intégrer des services externes sans modifier l’application principale.
Chaque module fonctionne comme une unité indépendante, avec sa propre logique, ses ressources et sa configuration. Cette architecture modulaire garantit que les développements sur mesure restent isolés et compatibles avec les futures mises à jour de NexoPOS.
Par conception, NexoPOS traite les modules comme des composants de premier plan du système, permettant un écosystème flexible et évolutif.
Architecture
Un module est structuré comme un composant autonome au sein de l’application. Il comprend généralement :
- Controllers: Handle application logic and user interactions
- Views: Define the user interface rendered within the dashboard
- Routes: Register accessible endpoints and navigation paths
- Assets: Provide JavaScript, CSS, or other frontend resources
- Configuration: Store module-specific settings and metadata
Tous les modules sont stockés dans le répertoire des modules et suivent une structure standardisée afin d’assurer la cohérence dans l’ensemble du système.
Génération de module
NexoPOS inclut une commande Artisan intégrée qui aide à générer un nouveau module avec la structure attendue. C’est la méthode recommandée pour démarrer un module, car elle prépare les fichiers et répertoires de base requis par le système.
Pour créer un module, ouvrez un terminal depuis la racine de votre installation NexoPOS et exécutez la commande suivante :
php artisan make:module
Une fois la commande exécutée, NexoPOS lancera un processus interactif et demandera une série de détails.
La première valeur à fournir est l’espace de noms du module. Il s’agit de l’identifiant interne du module et il est généralement écrit dans un format compact, tel que FooBar. Cet espace de noms est utilisé pour créer le répertoire du module et identifier le module en interne.
.
Ensuite, NexoPOS demande le nom du module. Contrairement au namespace, il s’agit du nom lisible par les humains qui peut être affiché aux utilisateurs. Par exemple, un espace de noms tel que FooBar peut utiliser un nom comme « Le module FooBar ».
L’invite suivante demande le nom de l’auteur. Elle sert à identifier la personne qui a créé le module et est stockée dans les métadonnées du module.
NexoPOS demande ensuite une brève description. Cette description explique brièvement l’objectif du module et permet d’en identifier le rôle.
Avant de générer les fichiers, la commande affiche un tableau récapitulatif contenant les informations fournies, notamment l’espace de noms, le nom, l’auteur, la description et la version. À ce stade, une confirmation est requise. Confirmer les informations permet à NexoPOS de poursuivre la génération.
Une fois confirmé, le système crée un nouveau dossier dans le répertoire modules en utilisant l’espace de noms fourni. Par exemple, si l’espace de noms est FooBar, le module généré sera créé sous modules/FooBar.
La structure générée inclut plusieurs répertoires et fichiers qui préparent le module à un développement ultérieur. Parmi eux, on trouve des dossiers pour la configuration, la logique CRUD, les événements, les façades, les champs, les classes HTTP, les e-mails, les migrations, les modèles, les fournisseurs, les ressources statiques publiques, les ressources, les routes et les services. Le module comprend également des fichiers essentiels tels que config.xml et le fichier principal de classe du module.
Cette structure générée fournit la base nécessaire pour commencer à développer des fonctionnalités tout en gardant le module organisé conformément aux normes de NexoPOS.
Recommandation
Afin d’assurer la compatibilité et la maintenabilité, les modules doivent toujours être créés à l’aide du générateur intégré fourni par NexoPOS.
Cela garantit l’alignement avec les normes du système et réduit le risque de problèmes structurels ou d’intégration.