Struct settingsfile::Settings
source · Implementations
sourceimpl<T> Settings<T>where
T: Format + Clone,
impl<T> Settings<T>where
T: Format + Clone,
sourcepub fn create_from(file: &File, config: T) -> Result<Settings<T>, Error>
pub fn create_from(file: &File, config: T) -> Result<Settings<T>, Error>
Loads the content of a File using the configuration. Doesn’t use
a path or doesn’t infer the path from the config because this method
is easier to do testing on to ensure everything behaves as expected
sourcepub fn create_from_or_empty(file: &File, config: T) -> Settings<T>
pub fn create_from_or_empty(file: &File, config: T) -> Settings<T>
Wrapper around load_from so the return value isn’t an result.
loads a new setting object from a path, or creates an empty object
if file doesn’t exist or errors in any way.
sourcepub fn load(&mut self) -> Result<(), Error>
pub fn load(&mut self) -> Result<(), Error>
loads from the file defined in ioconfig
if nothing exists it throws an error. This shouldn’t
be used for initalizing a new Settings, look at create and
create_from for that.
sourcepub fn load_from(&mut self, file: &mut File) -> Result<(), Error>
pub fn load_from(&mut self, file: &mut File) -> Result<(), Error>
loads into the current Setting with the buffer
of the file
sourcepub fn save(&self) -> Result<(), Error>
pub fn save(&self) -> Result<(), Error>
saves the setting to a file, uses the save_to buffer function
sourcepub fn save_to(&self, file: &File) -> Result<(), Error>
pub fn save_to(&self, file: &File) -> Result<(), Error>
saves the setting to a file buffer. Maybe done this way because of ease of writing good tests?
sourcepub fn get_value_absolute(&self, key_path: &str) -> Option<Type>
pub fn get_value_absolute(&self, key_path: &str) -> Option<Type>
normally you should always use get_value, as it properly splits
the key_path to get the correct value in the tree.
if you are working with a flattend Settings then get_value
will not work as it will attempt to split the key and it will find
nothing, this function will NEVER split the key
sourcepub fn get_value(&self, key_path: &str) -> Option<Type>
pub fn get_value(&self, key_path: &str) -> Option<Type>
looks for a key_path in dot notation and returns an Option
containing the value if it exists.
sourcepub fn set_value<A: ?Sized>(
&mut self,
key_path: &str,
value: &A
) -> Result<(), Error>where
A: SupportedType,
pub fn set_value<A: ?Sized>(
&mut self,
key_path: &str,
value: &A
) -> Result<(), Error>where
A: SupportedType,
sets the value of a key, uses a generic that must implement the SupportedType trait
sourcepub fn delete_key(&mut self, key_path: &str) -> Option<Type>
pub fn delete_key(&mut self, key_path: &str) -> Option<Type>
deletes the key and returns the current value, returns none if the key didn’t exist.
Trait Implementations
sourceimpl<T> Add<Settings<T>> for Settings<T>where
T: Format + Clone,
impl<T> Add<Settings<T>> for Settings<T>where
T: Format + Clone,
sourcefn add(self, other: Settings<T>) -> Settings<T>
fn add(self, other: Settings<T>) -> Settings<T>
implementing add so you should be able to use ‘+’ on two settings, useful
because you may want to combine settings from different locations.
Adding to Settings works by overlaying the two Settings on top of each
other, if the same “key” has multiple “values”, the “self” is overwritten with
the “other”. So Adding a Settings means you are overlaying it ontop of the
existing data.
sourceimpl<T> AddAssign<Settings<T>> for Settings<T>where
T: Format + Clone,
impl<T> AddAssign<Settings<T>> for Settings<T>where
T: Format + Clone,
sourcefn add_assign(&mut self, other: Settings<T>)
fn add_assign(&mut self, other: Settings<T>)
AddAssign follows the same logic as Add, and allows you to use += with
Settings