Admin Runique

Daemon & génération de code

Structure générée

src/admins/
  ├── README.md       ← avertissement : ne pas éditer manuellement
  ├── mod.rs          ← expose `routes` et `admin_state`
  └── admin_panel.rs  ← fichier principal : wrappers DynForm + admin_register()

admin_panel.rs

Contient pour chaque ressource déclarée dans admin! :

  • Un wrapper DynForm autour du formulaire Runique concret
  • Les closures CRUD : list_fn, get_fn, create_fn, update_fn, delete_fn, count_fn
  • Si list_filter est déclaré : une closure filter_fn par champ, qui charge les valeurs distinctes depuis la base (jusqu'à 100)
  • La configuration d'affichage (colonnes visibles, taille de page filtre) transmise via .display(…) sur le ResourceEntry
  • La fonction admin_register() qui construit le HashMap<String, ResourceEntry> chargé au boot

mod.rs

Ré-exporte routes et admin_state depuis admin_panel.


Le compromis : écrasement automatique

runique start supprime et régénère intégralement src/admins/ à chaque modification de src/admin.rs.

Toute modification manuelle dans ce dossier sera perdue lors de la prochaine régénération.

Quand basculer sur `cargo run`

Si des modifications manuelles du code généré sont nécessaires (logique métier spécifique, handler personnalisé), il faut arrêter runique start et passer à un workflow standard :

cargo run

Dans ce mode, src/admins/ n'est plus surveillé ni écrasé. Les modifications persistent.

Le README.md généré dans src/admins/ rappelle ce comportement directement dans le dépôt.

Autre section

SectionDescription
CLIFonctionnement de runique start
Macro admin!Déclaration des ressources administrables

Revenir au Sommaire