Struct ConfigNodeView 

#[non_exhaustive]
pub struct ConfigNodeView {
    pub path: String,
    pub display_value: String,
    pub kind: NodeKind,
    pub editable: bool,
}

One editable value inside a ConfigFileView.

Why a flat list of nodes instead of a tree

The TOML the user writes is nested, but the UI surface a GUI renders is usually flat (a properties panel, a form). Keeping the API flat with a dotted path string trades a tiny bit of GUI cleverness for a much simpler cross-language contract.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

path: String

Dotted TOML path (e.g. "listener.port", "service.rule_sets").

display_value: String

Current value, stringified for display. A GUI can format this however it wants; the value’s original type is in kind.

kind: NodeKind

What shape of value this node holds.

editable: bool

Whether the GUI should allow editing this field.

Trait Implementations

impl Clone for ConfigNodeView

fn clone(&self) -> ConfigNodeView

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ConfigNodeView

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Serialize for ConfigNodeView

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.