Skip to main content

NodeProcessor

bnto_core::processor

Trait NodeProcessor 

Source 
pub trait NodeProcessor {
    // Required methods
    fn name(&self) -> &str;
    fn process(
        &self,
        input: NodeInput,
        progress: &ProgressReporter,
        ctx: &dyn ProcessContext,
    ) -> Result<NodeOutput, BntoError>;

    // Provided methods
    fn validate(&self, _params: &Map<String, Value>) -> Vec<String> { ... }
    fn reserved_tokens(&self) -> &'static [&'static str] { ... }
    fn validate_raw(&self, _raw: &Map<String, Value>) -> Vec<String> { ... }
    fn platform_problems(
        &self,
        _params: &Map<String, Value>,
        _platforms: &[&str],
    ) -> Vec<String> { ... }
    fn count_keys(&self) -> &'static [&'static str] { ... }
    fn resolves_items(&self) -> bool { ... }
    fn process_batch(
        &self,
        input: BatchInput,
        progress: &ProgressReporter,
        ctx: &dyn ProcessContext,
    ) -> Result<NodeOutput, BntoError> { ... }
    fn metadata(&self) -> NodeMetadata { ... }
    fn declared_params(&self) -> Option<Vec<ParameterDef>> { ... }
}
Expand description

The contract that every node type must implement.

Currently synchronous – async is handled at the Web Worker level. wasm-bindgen doesn’t support async trait methods across the WASM boundary.

Required Methods§

Source

fn name(&self) -> &str

The processor’s type key (e.g., “image-compress”). Must match the key used in registry.register(). Convention: category-operation, kebab-case.

Source

fn process( &self, input: NodeInput, progress: &ProgressReporter, ctx: &dyn ProcessContext, ) -> Result<NodeOutput, BntoError>

Process a single input file and produce output.

Arguments:

  • &self — reference to the node processor instance
  • input — the file data, filename, MIME type, and config params
  • progress — callback to report progress to the UI (0-100%)
  • ctx — system access boundary (commands, temp files, env vars)

Returns:

  • Ok(NodeOutput) — processing succeeded, here are the results
  • Err(BntoError) — processing failed, here’s what went wrong

Provided Methods§

Source

fn validate(&self, _params: &Map<String, Value>) -> Vec<String>

Validate the input parameters before processing.

This is called BEFORE process() to catch configuration errors early (missing required params, invalid values, etc.) without doing any expensive file processing.

Returns a list of validation errors (empty = valid).

Default implementation passes validation. Override in specific node types to add parameter validation.

Source

fn reserved_tokens(&self) -> &'static [&'static str]

Tokens this processor fills in its params itself, after the executor (shell-run’s {{output_dir}}, {{url}}, each groups’ {{path}}). A value the executor fills in may not carry one: the processor couldn’t tell it from the recipe’s own. An entry ending in . ({{item.) covers every token it starts.

Default: none.

Source

fn validate_raw(&self, _raw: &Map<String, Value>) -> Vec<String>

Problems in the params as the recipe wrote them, before any template is filled — what validate can’t see once data is in, such as a data placeholder in a param that must be literal. The executor refuses the run on any, before a step starts; bnto check reports them.

Default: none.

Source

fn platform_problems( &self, _params: &Map<String, Value>, _platforms: &[&str], ) -> Vec<String>

Problems the params cause on some of the platforms the step can run on: the values {{ctx.platform}} may read there (macos, linux, windows, unknown), narrowed by the platform guards on its path. bnto check reports them (shell-run’s Windows-only powershell).

Default: none.

Source

fn count_keys(&self) -> &'static [&'static str]

Keys of the node-level NodeOutput.metadata that count something per call (e.g. files copied). When the node runs more than once — a per-file node over several files, a loop’s iterations — the executor adds these up in the node’s record instead of keeping the last call’s value.

Default: none, so every key keeps the last call’s value.

Source

fn resolves_items(&self) -> bool

True for a batch node that fills {{item.*}} in its params itself, once per incoming file (assert, report). Outside a loop there is no item to resolve them against once, so the executor hands them to the node as written instead of refusing them.

Default: false, so an unfilled {{item.*}} fails the node.

Source

fn process_batch( &self, input: BatchInput, progress: &ProgressReporter, ctx: &dyn ProcessContext, ) -> Result<NodeOutput, BntoError>

Process a batch of files together, producing combined output.

Override this for processors with InputCardinality::Batch (merge, zip, concat). The default falls back to calling process() per file and concatenating results — suitable for PerFile processors.

Source

fn metadata(&self) -> NodeMetadata

Return the processor’s self-describing metadata.

This tells consumers everything about this processor: what it’s called, what category it belongs to, what parameters it accepts, what files it handles, and whether it runs in the browser.

Every concrete processor SHOULD override this with its real metadata. The default returns a placeholder “unknown” metadata — useful for tests and mocks that don’t need real metadata.

Source

fn declared_params(&self) -> Option<Vec<ParameterDef>>

The params a run accepts for this node: its metadata’s, or None when the processor keeps the placeholder metadata() above (test mocks), which declares nothing. A run refuses any other param.

Dyn Compatibility§

This trait is dyn compatible.

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

Implementors§