feat: restructure project, implement askama templating #26
24
Cargo.lock
generated
@ -1487,25 +1487,6 @@ dependencies = [
|
||||
"unicode-normalization",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "include_dir"
|
||||
version = "0.7.4"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "923d117408f1e49d914f1a379a309cffe4f18c05cf4e3d12e613a15fc81bd0dd"
|
||||
dependencies = [
|
||||
"include_dir_macros",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "include_dir_macros"
|
||||
version = "0.7.4"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "7cab85a7ed0bd5f0e76d93846e0147172bed2e2d3f859bcc33a8d9699cad1a75"
|
||||
dependencies = [
|
||||
"proc-macro2",
|
||||
"quote",
|
||||
]
|
||||
|
||||
[[package]]
|
||||
name = "indexmap"
|
||||
version = "1.9.3"
|
||||
@ -2101,9 +2082,9 @@ dependencies = [
|
||||
|
||||
[[package]]
|
||||
name = "object"
|
||||
version = "0.36.1"
|
||||
version = "0.36.2"
|
||||
source = "registry+https://github.com/rust-lang/crates.io-index"
|
||||
checksum = "081b846d1d56ddfc18fdf1a922e4f6e07a11768ea1b92dec44e42b72712ccfce"
|
||||
checksum = "3f203fa8daa7bb185f760ae12bd8e097f63d17041dcdcaf675ac54cdf863170e"
|
||||
dependencies = [
|
||||
"memchr",
|
||||
]
|
||||
@ -3270,7 +3251,6 @@ version = "0.1.0"
|
||||
dependencies = [
|
||||
"axum",
|
||||
"clego",
|
||||
"include_dir",
|
||||
"tauri",
|
||||
"tauri-build",
|
||||
"tokio",
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
[workspace]
|
||||
resolver = "2"
|
||||
members = [
|
||||
|
florian_briand marked this conversation as resolved
|
||||
"clego",
|
||||
"tauri"
|
||||
"crates/clego",
|
||||
"crates/tauri"
|
||||
|
florian_briand marked this conversation as resolved
Outdated
florian_briand
commented
J'avais fait le choix de mettre les modules à la racine, plutôt que dans sous dossier crates, car ça vient, à mon goût, surcharger l'arborescence sans qu'on en ai réellement besoin n J'avais fait le choix de mettre les modules à la racine, plutôt que dans sous dossier crates, car ça vient, à mon goût, surcharger l'arborescence sans qu'on en ai réellement besoin n
theo
commented
les deux me vont, on peut partir sur ca les deux me vont, on peut partir sur ca
|
||||
]
|
||||
|
||||
|
After Width: | Height: | Size: 3.4 KiB |
|
After Width: | Height: | Size: 6.8 KiB |
|
After Width: | Height: | Size: 974 B |
|
After Width: | Height: | Size: 2.8 KiB |
|
After Width: | Height: | Size: 3.8 KiB |
|
After Width: | Height: | Size: 3.9 KiB |
|
After Width: | Height: | Size: 7.6 KiB |
|
After Width: | Height: | Size: 903 B |
|
After Width: | Height: | Size: 8.4 KiB |
|
After Width: | Height: | Size: 1.3 KiB |
|
After Width: | Height: | Size: 2.0 KiB |
|
After Width: | Height: | Size: 2.4 KiB |
|
After Width: | Height: | Size: 1.5 KiB |
|
After Width: | Height: | Size: 85 KiB |
|
After Width: | Height: | Size: 14 KiB |
@ -5,10 +5,37 @@ use tauri::{path::BaseDirectory, Manager};
|
||||
use tokio::sync::Mutex;
|
||||
use tower::{Service, ServiceExt};
|
||||
|
||||
async fn process_tauri_request(request: tauri::http::Request<>, router: axum:Router ){
|
||||
let (parts, body) = request.into_parts();
|
||||
let body = axum::body::Body::from(body);
|
||||
|
||||
let request = axum::extract::Request::from_parts(parts, body);
|
||||
|
||||
let response = match router.as_service().ready().await {
|
||||
Ok(ready_service) => ready_service.call(request).await,
|
||||
Err(_error) => panic!("Failed to get ready service"),
|
||||
};
|
||||
|
||||
let response = match response {
|
||||
Ok(response) => response,
|
||||
Err(_error) => panic!("Problem getting response from request."),
|
||||
};
|
||||
|
||||
let (parts, body) = response.into_parts();
|
||||
let body = match axum::body::to_bytes(body, usize::MAX).await {
|
||||
Ok(bytes) => bytes.to_vec(),
|
||||
|
florian_briand marked this conversation as resolved
Outdated
florian_briand
commented
Est-ce que tu sais ce que font ces empilements de Arc / Mutex et pourquoi c'est là ? Ou bien c'est un copier-coller ? J'avais justement essayé, dans la version précédente, de simplifier au maximum, pour éviter d'avoir une seule ligne de code qui viennent d'ailleurs et dont on n'ait pas la maîtrise. Est-ce que tu sais ce que font ces empilements de Arc / Mutex et pourquoi c'est là ? Ou bien c'est un copier-coller ?
J'avais justement essayé, dans la version précédente, de simplifier au maximum, pour éviter d'avoir une seule ligne de code qui viennent d'ailleurs et dont on n'ait pas la maîtrise.
florian_briand
commented
De plus, le code était + découpé et + lisible dans la version précédente ; il me parait préférable d'itérer sur l'existant plutôt que de venir tout écraser avec une autre façon de faire De plus, le code était + découpé et + lisible dans la version précédente ; il me parait préférable d'itérer sur l'existant plutôt que de venir tout écraser avec une autre façon de faire
theo
commented
Le Arc<Mutex> est utilise pour faire de la communication async dans rust, on peut pas vraiment faire sans. Pour Arc: "Arc is a smart pointer enabling sharing data between threads. Its name is a shortcut for "atomic reference counter". The way Arc works is essentially to wrap a value we're trying to share and act as a pointer to it. Arc keeps track of all of the copies of the pointer and as soon as the last pointer goes out of scope it can safely free the memory. " Pour Mutex: " Mutexes in many languages are treated like semaphores. You create a mutex object and you can guard a certain piece (or pieces) of the code with the mutex in a way that only one thread at a time can access the guarded place. In Rust Mutex behaves more like a wrapper. It consumes the underlying value and let's you access it only after locking the mutex. Typically Mutex is used with conjunction with Arc to make it easier to share it between threads." Donc c'en gros, vu qu'on veut une seul instance du router et qu'on fait de l'async, on peut pas faire sans. Article qui en parle: https://itsallaboutthebit.com/arc-mutex/ Pour ta remarque sur la maitrise du code: Le Arc<Mutex<V>> est utilise pour faire de la communication async dans rust, on peut pas vraiment faire sans.
Pour Arc: "Arc is a smart pointer enabling sharing data between threads. Its name is a shortcut for "atomic reference counter". The way Arc works is essentially to wrap a value we're trying to share and act as a pointer to it. Arc keeps track of all of the copies of the pointer and as soon as the last pointer goes out of scope it can safely free the memory. "
Pour Mutex: " Mutexes in many languages are treated like semaphores. You create a mutex object and you can guard a certain piece (or pieces) of the code with the mutex in a way that only one thread at a time can access the guarded place. In Rust Mutex behaves more like a wrapper. It consumes the underlying value and let's you access it only after locking the mutex. Typically Mutex is used with conjunction with Arc to make it easier to share it between threads."
Donc c'en gros, vu qu'on veut une seul instance du router et qu'on fait de l'async, on peut pas faire sans.
Article qui en parle: https://itsallaboutthebit.com/arc-mutex/
Pour ta remarque sur la maitrise du code:
1 - L'interface entre les deux libraires ser inevitablement un point de complexite, on evitera de faire ca dans le futur.
2 - Je pense que si on se heurte a des limite dans nos connaissances, il faudrait qu'on se pose la question si cela ne vaudrait pas le coup d'approfondir :)
theo
commented
Pour ton deuxième commentaire, Initialement, je pensais que la logique procédurale du code était claire et qu'il n'était pas nécessaire de la diviser en fonctions. Je préfère éviter d'ajouter des abstractions tant qu'elles ne sont pas nécessaires. Cela dit, je comprends ton point de vue sur l'importance de ne pas imposer une méthode différente sans raison valable. Mon intention n'était pas de manquer de respect à ton travail. Je vais proposer une version plus claire du code. J'attends tes retours :) Pour ton deuxième commentaire,
Initialement, je pensais que la logique procédurale du code était claire et qu'il n'était pas nécessaire de la diviser en fonctions. Je préfère éviter d'ajouter des abstractions tant qu'elles ne sont pas nécessaires.
Cela dit, je comprends ton point de vue sur l'importance de ne pas imposer une méthode différente sans raison valable. Mon intention n'était pas de manquer de respect à ton travail.
Je vais proposer une version plus claire du code. J'attends tes retours :)
|
||||
Err(_error) => panic!("Problem converting response body to bytes."),
|
||||
};
|
||||
|
||||
let response = tauri::http::Response::from_parts(parts, body);
|
||||
}
|
||||
|
||||
#[cfg_attr(mobile, tauri::mobile_entry_point)]
|
||||
pub fn run() {
|
||||
tauri::Builder::default()
|
||||
.setup(|app| {
|
||||
// Create a router and adds it the the app state
|
||||
|
||||
let resource_path_buf = app
|
||||
.path()
|
||||
.resolve("assets", BaseDirectory::Resource)
|
||||
@ -27,30 +54,6 @@ pub fn run() {
|
||||
|
||||
tauri::async_runtime::spawn(async move {
|
||||
let mut router = router.lock().await;
|
||||
|
||||
let (parts, body) = request.into_parts();
|
||||
let body = axum::body::Body::from(body);
|
||||
|
||||
let request = axum::extract::Request::from_parts(parts, body);
|
||||
|
||||
let response = match router.as_service().ready().await {
|
||||
Ok(ready_service) => ready_service.call(request).await,
|
||||
Err(_error) => panic!("Failed to get ready service"),
|
||||
};
|
||||
|
||||
let response = match response {
|
||||
Ok(response) => response,
|
||||
Err(_error) => panic!("Problem getting response from request."),
|
||||
};
|
||||
|
||||
let (parts, body) = response.into_parts();
|
||||
let body = match axum::body::to_bytes(body, usize::MAX).await {
|
||||
Ok(bytes) => bytes.to_vec(),
|
||||
Err(_error) => panic!("Problem converting response body to bytes."),
|
||||
};
|
||||
|
||||
let response = tauri::http::Response::from_parts(parts, body);
|
||||
|
||||
responder.respond(response);
|
||||
});
|
||||
})
|
||||
Packages :
tauri/srcdevientcrates/app-> Interfaces et code métier via Axum + Askama + HTMxtauri/src-tauridevientcrates/desktopclegodevientcrates/sesam-vitale