First off, congrats on writing a useful and powerful tool with a super readable codebase!
Problem
I'd like to use Grimoire as part of a web framework, preferably keeping my config and CSS in a database. It'd be convenient if I could implement a trait (or a few) for this, so I could e.g. deploy my application to a serverless provider or as a single-file container and rebuild my CSS when an admin user modifies the theme.
Solution
Essentially, I'd like a few currently private structs and functions which accept a directory to 1) be pub and 2) instead take perhaps a vector/map filled with reader/writers, or a single reader/writer in the case where they only use the directory to construct one file's path. Having access to say, ConfigJSON would be useful. It'd be nice to ultimately build shared and critical CSS to a string or writer for storage somewhere other than the filesystem, like in a db or hashmap.
Options
Honestly, the language is so well-specified I would be comfortable implementing this in a new crate if it's not something you're interested in for this project. Or with your architectural blessing, I could take a crack at rewriting the relevant parts of this crate to be less tied to the filesystem - without removing any existing fs-based functionality, of course.
First off, congrats on writing a useful and powerful tool with a super readable codebase!
Problem
I'd like to use Grimoire as part of a web framework, preferably keeping my config and CSS in a database. It'd be convenient if I could implement a trait (or a few) for this, so I could e.g. deploy my application to a serverless provider or as a single-file container and rebuild my CSS when an admin user modifies the theme.
Solution
Essentially, I'd like a few currently private structs and functions which accept a directory to 1) be pub and 2) instead take perhaps a vector/map filled with reader/writers, or a single reader/writer in the case where they only use the directory to construct one file's path. Having access to say,
ConfigJSONwould be useful. It'd be nice to ultimately build shared and critical CSS to a string or writer for storage somewhere other than the filesystem, like in a db or hashmap.Options
Honestly, the language is so well-specified I would be comfortable implementing this in a new crate if it's not something you're interested in for this project. Or with your architectural blessing, I could take a crack at rewriting the relevant parts of this crate to be less tied to the filesystem - without removing any existing fs-based functionality, of course.