Trait ViewLogic 

pub trait ViewLogic:
    Send
    + Sync
    + 'static {
    // Required methods
    fn name(&self) -> &'static str;
    fn title(&self) -> &'static str;
    fn render(
        &self,
        args: &ViewArgs,
        ctx: &Context,
    ) -> Result<ViewData, ApiError>;

    // Provided methods
    fn in_switcher(&self) -> bool { ... }
    fn params(
        &self,
        _ctx: &Context,
        _asked: &ViewArgs,
    ) -> Result<Vec<Param>, ApiError> { ... }
    fn act(
        &self,
        name: &str,
        _fields: &Fields,
        _args: &ViewArgs,
        _ctx: &Context,
    ) -> Result<String, ApiError> { ... }
}

One repository’s view.

params and render both run on every request, against one Context, so a view reading three tables reads each of them once however many of its parts consult them.

Required Methods

fn name(&self) -> &'static str

The route segment and ?view= value. It must be made of unreserved URL characters, and may not take a reserved name or one a table has; building a crate::Server over such a view panics.

fn title(&self) -> &'static str

The heading the page and the shell’s switcher show.

fn render(&self, args: &ViewArgs, ctx: &Context) -> Result<ViewData, ApiError>

Provided Methods

fn in_switcher(&self) -> bool

Whether the shell’s switcher lists this view.

A page about one thing, reached from a card that says which—one story, one branch—says no here. A switcher entry for it would open whichever one its parameters happen to default to, which is nobody’s question. It is served, linked to, opened by name from the command line, and titled by the shell exactly as any other view is; the top bar simply does not offer it.

fn params( &self, _ctx: &Context, _asked: &ViewArgs, ) -> Result<Vec<Param>, ApiError>

The controls at the top of the page, rebuilt per request like a schema, so a select can be filled from a table.

asked is what the address carried, before defaults are filled in, so one parameter’s options may depend on another’s value. A parameter whose options are built that way should give a default drawn from the same values: an answer the new options do not offer is replaced by that default rather than kept.

fn act( &self, name: &str, _fields: &Fields, _args: &ViewArgs, _ctx: &Context, ) -> Result<String, ApiError>

Write what an action asks for, and say in a sentence what was written.

name is the action a button on the page named, fields is what its form was filled in with, and args is what the page itself was asked plus what that form carried. The write goes through ctx, which is the same path a table’s save takes: read the rows, change them, and write the file back, so the ordering and the bytes are what the table’s own rules make them.

The sentence is shown to the reader and the page is then fetched again, so an action says what it did and never what the page should now show.

A view with no buttons that write implements none of this. The router refuses an action no button on the page offers, so the default is reached only where that check itself has gone wrong.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors