3.9 KiB
netslim-core
netslim-core est le socle réutilisable de la plateforme Netslim.
Il contient :
- le
Kerneltechnique ; - les modules partageables
Identity,Settings,AuditLog,Notifications,TaxonomyetMedia; - les tests d'architecture et de modules du socle.
Ce dépôt est conçu pour être consommé par des projets applicatifs séparés via Composer.
Installation depuis le dépôt Git en HTTPS
Pendant le développement du core
{
"repositories": [
{
"type": "vcs",
"url": "https://git.netig.net/netig/netslim-core.git"
}
],
"require": {
"netig/netslim-core": "^0.3@dev"
}
}
Après la première release taguée
{
"repositories": [
{
"type": "vcs",
"url": "https://git.netig.net/netig/netslim-core.git"
}
],
"require": {
"netig/netslim-core": "^0.1"
}
}
Option locale pendant le développement
Pour développer le core et une application consommatrice côte à côte, un path repository local reste pratique, mais ce n'est pas le mode de consommation par défaut :
{
"repositories": [
{
"type": "path",
"url": "../netslim-core"
}
],
"require": {
"netig/netslim-core": "^0.3@dev"
}
}
Ce que doit fournir une application consommatrice
Le package ne porte pas d'application concrète. Un projet consommateur doit fournir au minimum :
- son propre
config/modules.php; - son point d'entrée HTTP (
public/index.php) ; - ses templates applicatifs ;
- son pipeline d'assets.
Si l'application active Identity et exécute le provisionnement initial, elle doit aussi définir ADMIN_USERNAME, ADMIN_EMAIL et ADMIN_PASSWORD dans son .env. Ces variables ne sont plus exigées par le bootstrap du noyau seul.
Si l'application active Notifications, elle doit configurer MAIL_HOST, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD, MAIL_ENCRYPTION, MAIL_FROM et MAIL_FROM_NAME pour permettre l'envoi effectif des emails transactionnels.
Les templates du socle supposent en particulier :
- une feuille de styles servie sous
/assets/css/main.csspour les layouts@Kernel; - si l'UI admin du module
Mediaest utilisée, un script servi sous/assets/js/media-admin.js; - les caches, logs, médias et la base SQLite sont toujours résolus depuis le projet consommateur (
var/,public/media/,database/), jamais depuis le package installé dansvendor/; - la destination du back-office peut être redéfinie via
ADMIN_HOME_PATHsi l'application consommatrice n'utilise pas/admin.
Surface publique
Le socle expose principalement :
Netig\Netslim\Kernel\...pour le runtime public ;- les interfaces applicatives documentées des modules partagés (
Netig\Netslim\Identity\Application\*ServiceInterface,Netig\Netslim\Settings\Application\SettingsServiceInterface,Netig\Netslim\AuditLog\Application\AuditLogServiceInterface,Netig\Netslim\Notifications\Application\NotificationServiceInterface,Netig\Netslim\Taxonomy\Application\TaxonomyServiceInterface,Netig\Netslim\Media\Application\MediaServiceInterface) ; Netig\Netslim\Settings\Contracts\...;Netig\Netslim\AuditLog\Contracts\...;Netig\Netslim\Notifications\Contracts\...;Netig\Netslim\Taxonomy\Contracts\...;Netig\Netslim\Media\Contracts\...;- les classes
*Moduledes modules partagés.
La frontière détaillée entre API publique et API interne est documentée dans docs/PUBLIC_API.md.
Vérifications locales
composer install
composer qa
Gouvernance du package
docs/PUBLIC_API.mddéfinit la frontière supportée entre le package et les projets consommateurs ;
Quand
netslim-coreest installé via Composer, les chemins runtime détectent automatiquement la racine du projet consommateur pour les scripts CLI et les suites de tests qui n'appellent pas explicitementBootstrap::create().