Aller au contenu
Bondry
Acheter Bondry
Menu
Parcourir la documentation

Développer pour Bondry

Ce qu'est un module, ce qu'est un thème, et les règles qui valent pour les deux avant d'écrire une ligne.

Bondry est une application Laravel dotée d'un kernel qui charge les modules et les thèmes à l'exécution. Tout ce que vous construisez est un répertoire avec un manifeste, empaqueté en zip et installé depuis le panneau.

Les deux choses que vous pouvez construire#

Artefact Se trouve dans Manifeste
Module modules/<slug>/ module.json
Thème themes/<slug>/ theme.json

Un paquet de langue est un troisième type de paquet, mais il ne contient que des fichiers de traduction et un language.json, et n'a besoin d'aucun code.

Les règles qui ne plient pas#

Elles sont imposées par le kernel, pas par convention. Un paquet qui les enfreint est refusé à l'installation.

  1. Un module ne possède que ses propres tables. Elles portent le préfixe mod_<slug>_, les tirets devenant des tirets bas. Lire les données du core est permis ; créer, modifier ou supprimer quoi que ce soit en dehors de ce préfixe, non.
  2. La désinstallation ne retire que le module. Elle supprime ses tables et ses enregistrements de migration. Le core n'est pas touché, donc une réinstallation repart de zéro.
  3. Un module cassé ne fait jamais tomber le site. Le démarrage est résilient : un module qui lève une erreur est ignoré et le site continue.
  4. Un module livre ses propres fichiers de langue. Ils vivent dans modules/<slug>/resources/lang et sont chargés sous un espace de noms (slug::fichier.cle). Rien ne va dans les fichiers de langue du core.
  5. Jamais de clé étrangère entre modules. Un module peut être désinstallé pendant qu'un autre tourne.
  6. Aucune compilation chez l'acheteur. Le CSS et le JS sont livrés déjà compilés dans le paquet. C'est vous qui compilez, pas lui.
  7. Aucun script en ligne. Le produit applique une CSP stricte. Le comportement vit dans votre bundle JS.

Étendre sans toucher au core#

Deux mécanismes, et vous utiliserez les deux :

  • Les événements pour le comportement. Le kernel et les modules émettent des événements tels que l'inscription d'un membre ou la création d'un message ; vous écoutez dans votre boot().
  • Les emplacements d'interface pour l'UI. Le core déclare des emplacements (admin.menu, profile.tabs, search.sources, head.meta et d'autres) et n'importe quel module peut les remplir.

Rien n'oblige à modifier un fichier du core, et un module qui en modifie un perdra sa modification à la prochaine mise à jour.

Protéger une intégration entre modules#

Un module ne sait jamais si un autre est installé. Demandez, ne supposez pas :

PHP 
if (class_exists(\App\Support\Breadcrumbs::class)) {
    \App\Support\Breadcrumbs::push(__('directory::labels.title'), route('directory.index'));
}

if (\Illuminate\Support\Facades\Route::has('lms.catalog')) {
    // Proposez l'intégration seulement quand le LMS est là.
}

Où aller ensuite#