This document explains how to define and validate process inputs using the input DSL. Input definitions create structured boundaries for business processes, providing type safety, validation, and data normalization before process execution.
For information about the underlying Solid::Input class and its features, see page 4.3. For details on how input validation gates process execution, see page 3.1.
Processes define their input requirements using the input DSL. This creates a nested Input class that validates data before the process executes.
Title: Input DSL Class Creation Flow
The input method in Solid::Process::ClassMethods evaluates the provided block in the context of a new class that inherits from Solid::Input (or the configured input_class). The resulting class is stored as a Process::Input constant.
Sources: lib/solid/process/class_methods.rb11-20 lib/solid/input.rb3-5
The input block accepts a standard Ruby block where you define attributes, validations, and callbacks:
The input block creates PersonCreation::Input, which can be accessed via PersonCreation.input.
Sources: test/solid/process/input/block_test.rb8-29
When the input block is evaluated, the framework creates a new class that becomes the Process::Input constant.
Title: Input Class Creation Sequence
The input method performs several steps:
Input constant is already defined (returns it if so)Config.instance.input_class (defaults to Solid::Input)Input constant on the processSources: lib/solid/process/class_methods.rb11-20
The input method serves dual purposes:
| Call Pattern | Behavior |
|---|---|
input { ... } | Defines the Input class (first call only) |
input | Returns the Input constant (subsequent calls) |
ProcessClass.input | Class-level access to Input constant |
ProcessClass::Input | Direct constant access |
Sources: lib/solid/process/class_methods.rb11-20 test/solid/process/input/block_test.rb31-33
Attributes defined in the input block support type specifications and automatic type casting through ActiveModel::Attributes.
Input attributes support standard ActiveModel types:
| Type | Ruby Class | Example |
|---|---|---|
:string | String | attribute :name, :string |
:integer | Integer | attribute :age, :integer |
:float | Float | attribute :price, :float |
:decimal | BigDecimal | attribute :amount, :decimal |
:datetime | DateTime | attribute :created_at, :datetime |
:date | Date | attribute :birth_date, :date |
:boolean | TrueClass/FalseClass | attribute :active, :boolean |
Type Coercion: Values are automatically coerced to the specified type during instantiation.
Sources: test/solid/process/input/block_test.rb10-12
Attributes accept options for default values and other behaviors:
Static Defaults: Values that don't change between instances.
Dynamic Defaults: Lambdas evaluated at instantiation time.
Sources: test/solid/process/input/block_test.rb10
Input classes support the full suite of ActiveModel validations to ensure data integrity.
Title: Input Validation Flow
Input classes can use any ActiveModel validator:
When input validation fails, the process immediately returns a Failure(:invalid_input) result without executing the call method.
Sources: test/solid/process/input/block_test.rb19-21
Input classes commonly use before_validation callbacks to clean and normalize data before validation runs.
Title: Input Normalization Pipeline
The before_validation callback receives the input instance and can modify attributes before validation rules are applied. This ensures consistent data format regardless of how the input is provided.
Sources: test/solid/process/input/block_test.rb14-17
Input attributes support both static and dynamic default values.
| Default Type | Syntax | Evaluation Timing |
|---|---|---|
| Static | default: "value" | Class definition time |
| Dynamic (Lambda) | default: -> { value } | Instance creation time |
| Dynamic (Proc) | default: proc { value } | Instance creation time |
Lambda defaults are evaluated each time an input instance is created, allowing for unique values like UUIDs or timestamps.
Sources: test/solid/process/input/block_test.rb10
Input validation acts as a hard gate before process execution. Invalid input immediately returns a failure result without executing the process logic.
Title: Input Validation as Execution Gate
When Process.call is invoked, the framework:
before_validation callbacksinput.valid?Failure(:invalid_input, input: input_instance) immediatelycall methodThis pattern ensures that process logic only executes with valid, normalized data.
Sources: lib/solid/process/class_methods.rb11-20 test/solid/process/input/block_test.rb46-62
In addition to the input block, processes can use existing input classes via the input= method.
The input= method validates that the assigned class:
Class instance (not a module or other object)Solid::Model (checked via < operator)Input constant is already definedError on Invalid Class: Raises ArgumentError if the class doesn't meet requirements.
Error on Redefinition: Raises Solid::Process::Error if Input constant already exists.
Sources: lib/solid/process/class_methods.rb5-9 test/solid/process/dependencies/assignment_alias_test.rb52-60
The default base class for input definitions can be configured globally via Solid::Process.config.
Title: Input Class Configuration Flow
Configuration Requirements: The configured input_class must be a Class that includes Solid::Model. Attempting to set an invalid class raises ArgumentError.
Process-Specific Override: Individual processes can still use self.input = CustomClass to override the global default for that specific process.
Sources: lib/solid/process/config.rb1-35 test/solid/process/config_test.rb44-69
The framework provides clear error messages for common configuration issues.
Undefined Input: Processes without defined input classes raise descriptive errors indicating the missing input block.
Validation Failures: Standard ActiveModel validation error handling applies to all model objects.
Refresh this wiki