Skip to main content

Module modeladmin

Module modeladmin 

Source
Expand description

ModelAdmin — Django-style customisation surface.

Every model that ships through Admin::model::<M>() must implement ModelAdmin. The trait defines defaults for every method, so a project that wants standard behaviour writes a one- line empty impl:

use rustio_admin::ModelAdmin;

impl ModelAdmin for Course {}            // accept every default

Override only the methods you care about; the rest inherit the trait defaults:

impl ModelAdmin for Course {
    fn list_display() -> &'static [&'static str] {
        &["code", "title", "credit_hours", "is_published"]
    }
    fn list_filter()  -> &'static [&'static str] { &["status", "level"] }
    fn search_fields() -> &'static [&'static str] { &["code", "title"] }
    fn ordering()     -> &'static [&'static str] { &["code"] }
}

The values are captured into super::AdminEntry at registration time. The runtime reads them straight from the entry — no per-request virtual dispatch beyond the existing dyn AdminOps.

§Why no blanket impl?

An earlier draft shipped impl<T: AdminModel> ModelAdmin for T {} so every derived AdminModel would auto-pick-up the defaults. That collides with Rust’s coherence rules — without feature(specialization) (nightly-only), a blanket impl forbids any per-type impl, which would block project overrides entirely. The opt-in impl ModelAdmin for X {} is the standard stable-Rust pattern (serde, axum, std).

Structs§

BulkAction
One project-defined bulk action declared by ModelAdmin::bulk_actions. Static metadata only — see AdminOps::execute_bulk_action for the runtime dispatcher.
FieldValidationError
One validation failure attached to a project-driven validate call on ModelAdmin. Either targets a specific field (rendered inline next to its input) or surfaces globally in the form’s error banner.
Fieldset
One named group of fields on the change form. The framework’s default heuristic in [super::render::form_ctx] groups by name (Default / System / Advanced); a project that wants explicit section ordering returns a non-empty &'static [Fieldset] from ModelAdmin::fieldsets and the renderer honours that instead.
Inline
One related-children section to render below a parent model’s edit form. v1 surface: read-only listing of up to max_rows children matching <target.fk_field> = <parent.id>, each row a click-through to its own edit page, with an “Add new …” link that lands the operator on the child’s new form (the operator fills the parent FK manually for now).

Enums§

SortDir
One column to sort by, with direction.

Traits§

ModelAdmin
Django-style customisation surface for a registered admin model.

Functions§

parse_order_spec
Parse one ordering() slice entry. "-foo" → ("foo", Desc); "foo" → ("foo", Asc).