pub struct CodeLists { /* private fields */ }Expand description
Named EDIFACT-code-to-BO4E-name tables.
Implementations§
Source§impl CodeLists
impl CodeLists
Sourcepub fn resolve<'a>(
&'a self,
inline: Option<&'a BTreeMap<String, String>>,
named: Option<&str>,
) -> Option<&'a BTreeMap<String, String>>
pub fn resolve<'a>( &'a self, inline: Option<&'a BTreeMap<String, String>>, named: Option<&str>, ) -> Option<&'a BTreeMap<String, String>>
The table a structured mapping translates through: its own inline
enum_map, else the shared list its code_list names. An inline table
wins where both are given — the one rule every reader of a mapping
(engine, requirements, output shape) must apply alike.
pub fn get(&self, name: &str) -> Option<&BTreeMap<String, String>>
pub fn is_empty(&self) -> bool
pub fn len(&self) -> usize
pub fn names(&self) -> impl Iterator<Item = &String>
pub fn from_toml_str(text: &str) -> Result<Self, String>
Sourcepub fn read(path: &Path) -> Result<Self, String>
pub fn read(path: &Path) -> Result<Self, String>
Read the tables from path, or an empty set when the file is absent.
Absent is not an error: a mappings tree that names no list needs no file, and every unit test builds definitions in a temporary directory.
Sourcepub fn discover(start: &Path) -> Arc<Self> ⓘ
pub fn discover(start: &Path) -> Arc<Self> ⓘ
Find and read the tables for a directory inside a mappings tree.
Definitions are loaded from mappings/<FV>/<variant>/<pid>/, and every
loader is handed one of those directories rather than the tree root, so
the file is found by walking up. Results are cached per resolved path:
a format version builds a couple of thousand engines, and each re-read
would parse the same file again.