Commit Graph

128 Commits

Author SHA1 Message Date
8b7c2d4a9b
feat: Update avatar URLs in Avatar and LoginModal components 2024-10-02 12:05:36 +02:00
922598415c Merge pull request 'Setup de SeaORM + SQLite comme base de données' (#64) from feat/9_setup_db into main
### Détails

Comme défini dans le ticket #9 j'ai mis en place l'ORM "SeaORM" et une base de donnée en SQLite.

La PR contient également quelques modif annexes dont j'avais besoin :
- Un petit fix dans l'usage de get_router
- Une amélioration du système de chargement des fichiers de config (migration de ce module de anyhow à thiserror et système pour éviter les initialisations multiples)
- L'ajout d'un onglet "DEBUG" dans l'interface graphique, pour ajouter un exemple d'intéraction (Read & Write) avec la base de données

Il reste un comportement étrange : lorsqu'on érit dans la base de donnée, ça trigger l'autoreload/hotreload. Je n'ai pas cherché à résoudre le bug, car la suppression de HTMx devrait chambouler tout ça, donc ça ne me parait pas utile d'y passer du temps.

Closes #9

### Documentation

J'ai principalement suivi la documentation d'installation de SeaORM : https://www.sea-ql.org/SeaORM/docs/index/

Reviewed-on: #64
Reviewed-by: kosssi <simon@p4pillon.org>
2024-10-02 12:04:04 +02:00
5f20c4b893
fix: limit hot-reload to usefull situations 2024-09-24 18:33:54 +02:00
2ded18692d
feat: add a debug page calling database debug functions from the backend 2024-09-24 17:55:34 +02:00
8700354ad2
feat: fix CORS 2024-09-24 17:54:02 +02:00
0aa0aebbad
chore: Remove app crate 2024-09-24 17:39:57 +02:00
f3e2090e7f
chore: fixup "define workspace.dependencies and add sea-orm-cli as dev-dep" 2024-09-24 15:52:43 +02:00
90e79c1fa4
feat: fixup "add a DEBUG page to the UI with a database usage example" 2024-09-24 15:52:28 +02:00
777b7f2425
feat: fixup "setup seaorm and a first "debug" entity as example" 2024-09-24 15:52:08 +02:00
fcba21ef68
chore: define workspace.dependencies and add sea-orm-cli as dev-dep 2024-09-24 13:49:50 +02:00
0d51e3aa68
feat: add a DEBUG page to the UI with a database usage example 2024-09-24 13:49:50 +02:00
d43ee1c28f
feat: setup seaorm and a first "debug" entity as example 2024-09-24 13:49:50 +02:00
2ef527fa64
feat: add a function to init properly app library 2024-09-24 13:49:50 +02:00
502dc6f77d
feat: migrate utils::config from anyhow to thiserror and handle a "single config init" mechanism 2024-09-24 13:05:27 +02:00
345190dfeb Merge pull request 'Ajout d'un parcours utilisateur⋅ice de connexion / déconnexion' (#67) from feat/61_add_login_workflow into main
Reviewed-on: #67
Reviewed-by: kosssi <simon@p4pillon.org>

### Détails

- Ajout d'une interface "de base", avec une navbar (supprimée par la #65)
- Ajout d'un bouton de connexion, ouvrant une modale
- Sélection de l'utilisateur⋅ice au click ou par raccourci clavier
- Usage réactif d'un état partagé entre les composants, pour stocker l'information de l'utilisateur⋅ice connecté⋅e
- Menu dropdown de "profil" & Déconnexion

![Peek 24-09-2024 01-03](/attachments/4ceda5b3-26d9-4022-8923-e65a08da8dcd)

# Compatibilité

Les choix d'implémentation des éléments "dynamiques" de l'interface (modale, dropdown), encouragés par la documentation de DaisyUI, s'appuient sur les dernières évolutions de la norme HTML : il n'y a donc aucun javascript pour les gérer, c'est fait nativement par le navigateur.

Il faudrait vérifier si les librairies et framework qu'on utilise implémentent ces fonctionnements en "polyfill" pour les anciens navigateurs. Si ce n'est pas le cas, il faudra définir si :
- on cherche des polyfills adaptés
- on laisse comme ça sans rétro-compatibilité (pas très "numérique responsable")
- on fallback sur des implémentations plus "traditionnelles" mais rétro-compatibles

Closes #61
2024-09-24 12:57:34 +02:00
5712d898a5 feat: Add a client-side only user selection interface 2024-09-24 12:56:50 +02:00
3bd0a02b62 feat: implement a simple navbar 2024-09-24 12:56:50 +02:00
167a1fbbc2
Merge pull request 'Refactoring de l'interface : migration d'un monolithe HTMx vers un client Nuxt + serveur Axum' (#66) from feat/65_move_out_htmx_with_axum_backend_and_nuxt_frontend into main
Reviewed-on: #66
Reviewed-by: kosssi <simon@p4pillon.org>

Implémentation des réflexions menées dans #65 :
- Suppression de la crate `app`, qui était un serveur axum exposant du HTMx, embedded dans le Tauri de la crate `desktop`
- Création d'un module Typescript, `frontend`, basé sur NuxtJS et générant une application statique
- Ré-écriture complète de la crate `desktop` pour encapsuler l'application statique générée par `frontend`
- Création d'une crate `backend`, serveur axum ayant pour objectif de servir de backend à l'interface, en particulier pour centraliser les accès à une base de donnée unique

- J'ai ré-utilisé TailwindCSS, mais au travers du module Nuxt dédié ; la génération est donc propre et automatisée, sans même nécessiter de configuration
- J'ai rajouté une "surcouche" à Tailwind, DaisyUI plutôt que de re-partir sur Flowbite ; ça fournit un ensemble de composants, mais de manière moins intrusive et "opinionated"

cf #65

- [Nuxt](https://nuxt.com/)
- [DaisyUI](https://daisyui.com/)
- [@nuxtjs/tailwindcss](https://tailwindcss.nuxtjs.org/)
2024-09-24 12:53:47 +02:00
f11e2502dd
feat: handle axum errors with anyhow 2024-09-23 18:56:17 +02:00
43bb2c40de
feat: improve README 2024-09-23 18:56:16 +02:00
54870b0d0f
feat: add the hot-reload on backend crate 2024-09-23 18:56:16 +02:00
a50d951af7
feat: setup a backend server with axum 2024-09-23 18:56:16 +02:00
2e057eee01
feat: add DaisyUI for easy components styling and dark mode handling 2024-09-23 18:56:16 +02:00
bc33bd48e8
feat: add a loader for SPA javascript loading 2024-09-23 18:56:16 +02:00
62decb3314
feat: setup tailwindcss in frontend 2024-09-23 18:56:16 +02:00
339377b838
fix: a Anyhow error handling is missing in ssvlib_demo 2024-09-23 18:56:16 +02:00
71ea6423bc
fix: invalid borrowing of assets_path in get_router 2024-09-23 18:56:16 +02:00
cad2390649
feat: replace desktop by a fresh Tauri install, and add a new frontend module using Nuxt 2024-09-23 18:56:16 +02:00
ca2a0ace71 Merge pull request 'Rendre le système de fichier de configuration runtime fonctionnel en dev et en release' (#56) from fix/55_move_env_config_into_consistent_dirs into main
Reviewed-on: #56
Reviewed-by: kosssi <simon@p4pillon.org>

# Détails

- Rajoute une librairie d'utilitaires crates/utils
- Rajoute des fonctions de gestion des fichiers et dossiers de configuration dans la lib utils, dont une fonction de chargement du fichier de config approprié
- Remplace le chargement d'un .env relatif au CARGO_MANIFEST_DIR de la librairie sesam-vitale par la fonction de chargement de config

La fonction de chargement de config génère une hiérarchie d'emplacements de fichiers de config (.env dans : dossier courant, dossier manifest, dossier système) et charge le "plus proche", afin de permettre d'avoir une configuration stable au niveau système, mais de pouvoir la surcharger facilement en local, en particulier lors de phases de développement).
Pourquoi ?

L'usage de CARGO_MANIFEST_DIR pour trouver le fichier de configuration n'était pas viable, car cette variable d'environnement n'existe que lors d'un lancement via cargo run, mais pas lors d'un appel direct à l'executable buildé.
La nouvelle implémentation est maintenant totalement compatible, autant avec des approches de surcharge en développement que pour de installations pérennes sur un système.

# Documentation

Le chemin standard des fichiers de config, spécifique à chaque OS, est obtenu à l'aide de la librairie directories-rs

Closes #55
2024-08-30 18:29:56 +02:00
f16986ce26
refacto: explicit dotenv import in sesam-vitale/build.rs 2024-08-30 18:28:29 +02:00
f56439c9c5
feat: initialize a utils lib with config functions handling config files in local and standard OS directories 2024-08-30 18:28:29 +02:00
90ff593438 Merge pull request 'Implémentation "HATEOAS" de l'interface pour HTMX et update des URLs qui fonctionne !' (#57) from feat/54_update_url_on_navbar_navigation into main
Reviewed-on: #57
Reviewed-by: kosssi <simon@p4pillon.org>

Implémente une approche plus respectueuse de "HATEOAS" comme nécessité par HTMX.

Dans cette approche, les routes des pages, comme /index ou /cps, ont, par défaut, un rendu "complet", comme cela serait si l'on n'utilisait pas HTMX.
Certains helpers sont utilisés pour éviter la duplication de code (entre particulier une "macro" Jinja pour la navbar).

Un "Extractor" issu de axum-htmx permet d'identifier quand une requête sur ces pages est issue d'un appel htmx, et permet de générer un rendu "simplifié", ne contenant (quasiment) que les éléments HTML ayant leur contenu qui change.
Par exemple, la page /cps, dans le cadre d'une requête htmx (hx-request=true), ne retourne que : une nouvelle balise <title>, la navbar (pour changer le design de l'élément "courant") et le contenu de la page. Tout le contenu de <head> ou les div qui encapsulent l'ensemble de la page ne sont pas re-envoyé.

Cela permet de mettre à jour les URLs dans la barre du navigateur, sans provoquer les problèmes de rechargement de page identifié dans le ticket #54.

Au passage, cette PR organise les templates d'une manière qui me parait un peu plus "claire" qu'avant :

- Les "pages", correspondant à des routes réelles, sont définies dans app/src/pages
- Les "composants", comme la navbar, qui ont vocation à être "inséré" (plutôt par des includes ou des appels de fonctions), sont définis dans app/src/components

L'avantage de leur présence dans le dossier src est qu'on peut sans problème mettre à côté les fichiers .rs qui leur correspondent.

La PR #53 et le ticket #54 avaient éclairé un problème lorsqu'on souhaitait pouvoir refléter la navigation dans l'URL du navigateur. Cette PR corrige ce problème en adoptant une approche plus respectueuse de la philosophie de HTMX.

- La nouvelle librairie axum-htmx qui offre des helpers pour faire du HTMX dans Axum
- Un repo' d'exemple intéressant, du même auteur, qui propose certaines approches pour gérer les "partials" (le rendu différentiel selon qu'on a une requête HTMX ou pas)

Closes #46
Closes #54
2024-08-30 18:25:53 +02:00
216eb73757
fixup! refacto: move home code into a dedicated file and rename index to home everywhere 2024-08-27 11:28:36 +02:00
d4e565601a fix: make darkmode work by removing hardcoded tailwindcss from flowbite 2024-08-27 11:19:59 +02:00
c39ae44d74 docs: add some comments on useful locations 2024-08-27 11:19:59 +02:00
b7fcfe3792 refacto: move home code into a dedicated file and rename index to home everywhere 2024-08-27 11:19:59 +02:00
ab908f2664 fix: Small translations and misspelled IDs 2024-08-27 11:19:59 +02:00
7d4dc81df2 feat: implement htmx with partials on index and cps pages 2024-08-27 11:19:59 +02:00
2236a7219b refacto: remove old_* directories 2024-08-27 11:19:59 +02:00
3e9e8ecacc chore: update style.css 2024-08-27 11:19:59 +02:00
8ce18e53d5 feat: Rewrite routes, pages and components to be more HATEOAS 2024-08-27 11:19:59 +02:00
7487b34a17 refacto: rename html and rs templates dirs to old_* 2024-08-27 11:19:59 +02:00
217667253a feat: Add hx-push-url attribute to nav menu item 2024-08-27 11:19:59 +02:00
6dbf5b5438 feat: Add HX-Request header extraction to CPS endpoint 2024-08-27 11:19:59 +02:00
0e2e863bc0 Merge pull request 'fix: #50 - Correction des noms de module utilisés dans le template gitea de rapport de bug' (#59) from fix/50_use_correct_crates_labels_on_gitea into main
Reviewed-on: #59
Reviewed-by: kosssi <simon@p4pillon.org>

Les noms utilisés dans le template par défaut lors d'une création d'un ticket de Bug étaient les "anciens" noms (Cargo, Tauri ...)

Cette PR :
- Ajoute quelques options (docs, scripts ...)
- Remplace les anciens noms par des labels plus compréhensifs et les noms des "crates" ou dossiers correspondant
2024-08-27 10:43:16 +02:00
307bdf8fa6
fix: update module options in BUG_REPORT.yaml template 2024-08-26 22:36:53 +02:00
32009e2f00 Merge pull request 'Implémentation d'une première approche de gestion des erreurs' (#52) from feat/handle_errors_rustly into main
# Détails

Implémente (en partie) les "bonnes pratiques" de gestion des erreurs Rust décrites dans le ticket #34

Cette PR se concentre beaucoup sur la gestion des erreurs "internes" et peu sur la manière dont on les expose à l'extérieur (API) ou les trace (dans des logs ou sur une app de suivi de logs). Une deuxième phase de travail sera nécessaire pour cela.

De même, les choix faits à de nombreux endroits sont très perfectibles :

- les noms des erreurs et enums ne semblent pas toujours au top
- certains "fallback" pourraient sans doute être améliorés
- certaines erreurs pourraient peut-être remonter + de contexte
- l'usage des librairies d'aide (anyhow et thiserror) ne sont pas uniformes

Cela dit, il est difficile de vraiment affiner ces éléments sans être dans des situations concrètes et réalistes. Je pense donc que c'est à force d'itération, en situation concrète et au fur et à mesure des relectures de code en DA que nous améliorerons ces points.

# Pourquoi ?

La gestion des erreurs en Rust est extrêmement puissante, permettant de construire des infrastructures où les "bugs" inattendus sont quasiment inexistants. Pour cela, un certain nombre de bonnes pratiques sont à suivre dans la gestion des retours d'erreurs des fonctions et des programmes à plus haut niveau.

# Documentation

CF #34

Reviewed-on: #52
Reviewed-by: theo <theo.lettermann@gmail.com>
Reviewed-by: kosssi <simon@p4pillon.org>
2024-08-22 20:56:12 +02:00
1561fd2a44
feat: add documentation about errors handling in docs/errors.md 2024-08-20 22:33:57 +02:00
4d9f6e2638
chore: update Cargo.lock according to previous branch commits 2024-08-15 19:30:28 +02:00
760a9cd92c
feat: [sesam-vitale] Use thiserror, anyhow and expect to properly handle errors instead of unwrap 2024-08-15 19:28:13 +02:00