<commit_before># Module

Ici, nous allons voir en détails tout ce qui couvre les modules de Beluga de façon générale. En premier, nous verrons ce qu'ils _sont_ et _comment_ ils sont organisés. Ensuite, nous nous pencherons sur la façon dont ils s'intègrent à Beluga. Une fois ceci en main, nous apprendrons comment rajouter vos propres modules.

## Concept

Les modules de beluga sont la partie contenant les fonctionnalités proposées à l'utilisateur. Celles-ci étant regroupées en modules de par leur dépendances (exemple : la fonctionnalité `enregistrer utilisateur` et `connecter utilisateur` sont réunies au sein du module `account`).
Ce découpage en modules permet aux développeurs de n'embarquer que le code contenant les fonctionnalités qu'il désire utiliser, et donc ajuster le poids de Beluga par rapport à l'utilisation qui en est faite.

## Structure

Dans Beluga, nous avons choisis de rendre le plus facile possible l'ajout de nouveaux modules aux collaborateurs. Pour cette raison, nous suivons le paradigme de _convention over configuration_. Concrètement, cela signifie que certains dossiers, fichiers et fonctions sont nécessaires pour que Beluga soit en mesure de détecter et d'utiliser automatiquement les différentes fonctionalités des modules.
De plus, nous suivons une convention de nommage très stricte permettant de facilement pouvoir naviguer d'un module à l'autre. Afin de mieux illustrer la différence entre les conventions _simples_ et celles _nécessaires_, ces dernières seront précédées d'un mot en __gras__. 

Le seul défaut de cette approche est qu'elle rend plus dure, au premier abord, de trouver pourquoi un module n'est pas entièrement reconnu par Beluga. Pour cette raison, nous avons créé un script d'auto-génération d'un module (cf: Ajouter votre propre module).

### Filesystem

Les modules se trouvent sous le dossier `beluga/module`. Ils __doivent__ respecter l'architecture dossier minimale suivante afin d'être correctement reconnus et chargés par Beluga :

``` 
module_root/
│
│─── api/          : API used by Beluga dispatcher
│─── js/           : Javascript files
│─── locale/       : JSon files for localization 
│─── view/         : All files related to the html output
     │─── css/
     │─── locale/
     └─── tpl/
└─── widget/       : Widgets class files
```
Les autres dossiers couramment utilisés, tels que `exception` et `model`, sont purement présents dans un soucis d'organisation et d'esthétique.

### Détails du contenu des dossiers

#### Racine du module

À la racine du module, les fichiers __devant__ être exposés sont *l'interface* (simplement nommée avec le nom du module) et *l'implémentation* (nom du module + "Impl"). Ces deux fichiers **doivent** respectivement étendre `Module` et `ModuleImpl`.<commit_msg>Corrected some mistakes in module.md<commit_after># Module

Ici, nous allons voir en détails tout ce qui couvre les modules de Beluga de façon générale. En premier, nous verrons ce qu'ils _sont_ et _comment_ ils sont organisés. Ensuite, nous nous pencherons sur la façon dont ils s'intègrent à Beluga. Une fois ceci en main, nous apprendrons comment rajouter vos propres modules.

## Concept

Les modules de beluga sont la partie contenant les fonctionnalités proposées à l'utilisateur. Celles-ci étant regroupées en modules de par leurs dépendances (exemple : les fonctionnalités `enregistrer utilisateur` et `connecter utilisateur` sont réunies au sein du module `account`).
Ce découpage en modules permet aux développeurs de n'embarquer que le code contenant les fonctionnalités qu'il désire utiliser, et donc ajuster le poids de Beluga par rapport à l'utilisation qui en est faite.

## Structure

Dans Beluga, nous avons choisi de rendre le plus facile possible l'ajout de nouveaux modules aux collaborateurs. Pour cette raison, nous suivons le paradigme de _convention over configuration_. Concrètement, cela signifie que certains dossiers, fichiers et fonctions sont nécessaires pour que Beluga soit en mesure de détecter et d'utiliser automatiquement les différentes fonctionalités des modules.
De plus, nous suivons une convention de nommage très stricte permettant de facilement pouvoir naviguer d'un module à l'autre. Afin de mieux illustrer la différence entre les conventions _simples_ et celles _nécessaires_, ces dernières seront précédées d'un mot en __gras__. 

Le seul défaut de cette approche est qu'elle rend plus dure, au premier abord, de trouver pourquoi un module n'est pas entièrement reconnu par Beluga. Pour cette raison, nous avons créé un script d'auto-génération d'un module (cf: Ajouter votre propre module).

### Filesystem

Les modules se trouvent sous le dossier `beluga/module`. Ils __doivent__ respecter l'architecture dossier minimale suivante afin d'être correctement reconnus et chargés par Beluga :

``` 
module_root/
│
│─── api/          : API used by Beluga dispatcher
│─── js/           : Javascript files
│─── locale/       : JSon files for localization 
│─── view/         : All files related to the html output
     │─── css/
     │─── locale/
     └─── tpl/
└─── widget/       : Widgets class files
```
Les autres dossiers couramment utilisés, tels que `exception` et `model`, sont purement présents dans un soucis d'organisation et d'esthétique.

### Détails du contenu des dossiers

#### Racine du module

À la racine du module, les fichiers __devant__ être exposés sont *l'interface* (simplement nommée avec le nom du module) et *l'implémentation* (nom du module + "Impl"). Ces deux fichiers **doivent** respectivement étendre `Module` et `ModuleImpl`.
{'fraction_non_alphanumeric': 0.06042675273444504, 'fraction_numerical': 0.0, 'mean_word_length': 4.544731610337972, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2048915', 'n_tokens_mistral': 1674, 'n_tokens_neox': 1690, 'n_words': 777}