Enum BoundInput 

pub enum BoundInput {
    Value,
    Checkbox,
    Radio,
    Unknown,
    File,
    SelectMultiple,
}

What a bind={field} on an element actually WRITES — the one place the whole language decides, so no two walks can disagree about a checkbox.

An <input type="text"> holds its state in value, a string. An <input type="checkbox"> (or type="radio") holds its state in checked, a PRESENCE — and not in the checked ATTRIBUTE either, which is defaultChecked. Writing a checkbox’s state as a value renders value="true" and draws the box UNCHECKED while the page believes it is checked, which is worse than not supporting bind on a checkbox at all: the author has been told their binding was understood.

Variants

Value

value — a text/number/date input, a <textarea>, a <select>.

Checkbox

checked, and a click FLIPS it — a checkbox.

Radio

checked, and a click SELECTS it — a radio. Split from BoundInput::Checkbox because the two differ exactly where it matters: clicking a chosen radio leaves it chosen, and a lowering that flipped it would let a second click deselect it, which no radio group has ever done.

Unknown

The element’s type is computed, so which of the two this is cannot be known until the page runs. Refused rather than guessed: guessing Value is the silent wrong answer above.

File

<input type="file">. A browser will not let a page set a file input’s value — a deliberate restriction, because a page that could would be a page that can read any file on your disk by naming it. So a bind here writes nothing, silently, forever.

SelectMultiple

<select multiple>. Its value is the LIST of chosen options, so writing one text into it selects at most one and reading it back returns at most one — a visitor’s other selections vanish with no error anywhere.

Implementations

impl BoundInput

pub const UNKNOWN_REFUSAL: &'static str = "a `bind` sits on an element whose `type` is computed, so whether it binds a value or a \ checkbox's checked state cannot be known until the page runs. Write the type literally \ (`type=\"checkbox\"` or `type=\"text\"`), or use two elements"

Why a BoundInput::Unknown binding is refused — held here, in ONE place, so the checker and the lowering refuse it in the same words. Two refusals of the same thing in different words send whoever reads one message searching for the other.

pub fn writes_checked(self) -> bool

Whether this binding writes the checked PROPERTY rather than value.

pub fn refusal(self) -> Option<&'static str>

Why this binding cannot be lowered, or None when it can.

★ TOTAL, AND THAT IS THE POINT. A new variant does not compile until somebody decides whether it lowers or is refused BY NAME — silently absent is not one of the options, which is the discipline action_verb_tier_lock holds over every UiStmt. Two of these arms exist because the question used to be asked of the ATTRIBUTES ALONE: with no tag to look at, a file input and a multiple select both fell through to Value and got a text write that does nothing, while the author was told their binding was understood.

Trait Implementations

impl Clone for BoundInput

fn clone(&self) -> BoundInput

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for BoundInput

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

Formats the value using the given formatter.

impl PartialEq for BoundInput

fn eq(&self, other: &BoundInput) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Copy for BoundInput

impl Eq for BoundInput

impl StructuralPartialEq for BoundInput