Decide how to handle stringified booleans in configuration #2

New issue

Open

opened 2025-10-03 22:34:52 +02:00 by federico · 1 comment

federico commented

2025-10-03 22:34:52 +02:00

Collaborator

src/core/config/settings.rs has these:

pub struct Global {
    pub render_on_save: bool,
    pub external_api: bool,
    pub dynamic_render: bool,
    ...
}

pub struct GlobalEdit {
    pub render_on_save: String,
    pub external_api: String,
    pub dynamic_render: String,
    ...
}

GlobalEdit's values later get merged into Global. Those String values get booleanified like this:

current.global.render_on_save = edit.global.render_on_save == "true";

@ro mentioned that they are strings in the JSON to be able to accept configuration files that come from the PHP verison of Fipamo.

Serde can be told to treat those fields specially, and to be able to parse them as booleans or as strings. Should I just make it do that? Are there any other considerations for being able to reuse configurations from the PHP Fipamo?

`src/core/config/settings.rs` has these: ```rust pub struct Global { pub render_on_save: bool, pub external_api: bool, pub dynamic_render: bool, ... } pub struct GlobalEdit { pub render_on_save: String, pub external_api: String, pub dynamic_render: String, ... } ``` `GlobalEdit`'s values later get merged into `Global`. Those `String` values get booleanified like this: ```rust current.global.render_on_save = edit.global.render_on_save == "true"; ``` @ro mentioned that they are strings in the JSON to be able to accept configuration files that come from the PHP verison of Fipamo. Serde can be told to treat those fields specially, and to be able to parse them as booleans or as strings. Should I just make it do that? Are there any other considerations for being able to reuse configurations from the PHP Fipamo?