Struct DiagramContext 

pub struct DiagramContext<'a, 'c, 'w, 's, 'b> {
    pub builder: &'c mut Builder<'w, 's, 'b>,
    pub registry: &'a DiagramElementRegistry,
    pub operations: Operations,
    pub templates: &'a Templates,
    pub on_implicit_error: &'a OperationRef,
    /* private fields */
}

Fields

builder: &'c mut Builder<'w, 's, 'b>

registry: &'a DiagramElementRegistry

operations: Operations

templates: &'a Templates

on_implicit_error: &'a OperationRef

Implementations

impl<'a, 'c, 'w, 's, 'b> DiagramContext<'a, 'c, 'w, 's, 'b>

pub fn infer_input_type_into_target( &self, id: impl Into<OperationRef>, ) -> Result<Option<TypeInfo>, DiagramErrorCode>

Infer the TypeInfo for the input messages into the specified operation.

If this returns None then not enough of the diagram has been built yet to infer the input type. In that case you can return something like Ok(BuildStatus::defer("waiting for an input")).

The workflow builder will ensure that all outputs targeting this operation are compatible with this message type.

During the ConnectIntoTarget phase all information about outputs going into this target will be drained, so this function is generally not useful during that phase. If you need to retain this information during the ConnectIntoTarget phase then you should capture the TypeInfo that you receive from this function during the BuildDiagramOperation phase.

pub fn infer_buffer_message_type_from_hints( &self, id: impl Into<OperationRef>, ) -> Result<Option<TypeInfo>, DiagramErrorCode>

pub fn redirect_infer_input_type( &self, redirect_to: &OperationRef, visited: &mut HashSet<OperationRef>, ) -> Result<Option<Arc<dyn InferMessageType>>, DiagramErrorCode>

Redirect the inference of an input type to another input. This can be used by implementations of ConnectIntoTarget whose input types are dependent on a downstream operation.

pub fn add_output_into_target( &mut self, target: impl Into<OperationRef>, output: DynOutput, )

Add an output to connect into a target.

This can be used during both the BuildDiagramOperation phase and the ConnectIntoTarget phase.

Arguments

• target - The operation that needs to receive the output
• output - The output channel that needs to be connected into the target.

pub fn set_input_for_target( &mut self, operation: impl Into<OperationRef>, input: DynInputSlot, trace_info: TraceInfo, ) -> Result<(), DiagramErrorCode>

Set the input slot of an operation. This should not be called more than once per operation, because only one input slot can be used for any operation.

This should be used during the BuildDiagramOperation phase to set the input slot of each operation with standard connection behavior. Standard connection behavior means that implicit serialization or deserialization will be applied to its inputs as needed to match the DynInputSlot that you provide.

If you need non-standard connection behavior then you can use Self::set_connect_into_target to set the exact connection behavior. No implicit behaviors will be provided for Self::set_connect_into_target, but you can enable those behaviors using ImplicitSerialization and ImplicitDeserialization.

This should never be used during the ConnectIntoTarget phase because all connection behaviors must already be set by then.

pub fn set_connect_into_target<C: ConnectIntoTarget + 'static>( &mut self, operation: impl Into<OperationRef>, connect: C, ) -> Result<(), DiagramErrorCode>

Set the implementation for how outputs connect into this target. This is a more general method than Self::set_input_for_target.

There will be no additional connection behavior beyond what you specify with the object passed in for connect. That means we will not automatically add implicit serialization or deserialization when you use this method. If you want your connection behavior to have those implicit operations you can use ImplicitSerialization and ImplicitDeserialization inside your connect implementation.

This should never be necessary to use this during the ConnectIntoTarget phase because all connection behaviors should already be set by then.

pub fn set_buffer_for_operation( &mut self, operation: impl Into<OperationRef> + Clone, buffer: AnyBuffer, trace: TraceInfo, ) -> Result<(), DiagramErrorCode>

Set the buffer that should be used for a certain operation. This will also set its connection callback.

pub fn create_buffer_map( &self, inputs: &BufferSelection, ) -> Result<BufferMap, String>

Create a buffer map based on the buffer inputs provided. If one or more of the buffers in BufferInputs is not available, get an error including the name of the missing buffer.

pub fn set_listen_type_hints( &mut self, message_type: &TypeInfo, buffers: &BufferSelection, ) -> Result<(), DiagramErrorCode>

pub fn set_access_type_hints( &mut self, message_type: &TypeInfo, buffers: &BufferSelection, ) -> Result<(), DiagramErrorCode>

pub fn get_implicit_error_target(&self) -> OperationRef

pub fn into_operation_ref(&self, id: impl Into<OperationRef>) -> OperationRef

pub fn into_child_operation_ref( &self, id: &OperationName, child_id: impl Into<OperationRef>, ) -> OperationRef

pub fn add_child_operation<T: BuildDiagramOperation + 'static>( &mut self, id: &OperationName, child_id: &OperationName, op: &Arc<T>, sibling_ops: Operations, scope: Option<BuilderScopeContext>, )

Add an operation which exists as a child inside another operation.

For example this is used by section templates to add their inner operations into the workflow builder.

Operations added this way will be internal to the parent operation, which means they are not “exposed” to be connected to other operations that are not inside the parent.

Use the scope argument if the child operation exists in a different scope than the parent. For the child of a Section, this is None.

pub fn redirect_to_child_input( &mut self, section_id: &OperationName, exposed_id: &OperationName, child_id: &NextOperation, ) -> Result<(), DiagramErrorCode>

Create a connection for an exposed input that allows it to redirect any connections to an internal (child) input.

Arguments

• section_id - The ID of the parent operation (e.g. ID of the section) that is exposing an operation to its siblings.
• exposed_id - The ID of the exposed operation that is being provided by the section. E.g. siblings of the section will refer to the redirected input by { section_id: exposed_id }
• child_id - The ID of the operation inside the section which the exposed operation ID is being redirected to.

This should not be used to expose a buffer. For that, use Self::redirect_to_child_buffer.

pub fn redirect_to_child_buffer( &mut self, section_id: &OperationName, exposed_id: &OperationName, child_id: &NextOperation, ) -> Result<(), DiagramErrorCode>

Same as Self::redirect_to_child_input, but meant for buffers.

pub fn redirect_exposed_output_to_sibling( &mut self, section_id: &OperationName, output_id: &OperationName, sibling_id: &NextOperation, ) -> Result<(), DiagramErrorCode>

Create a connection for an exposed output that allows it to redirect any connections to an external (sibling) input. This is used to implement the "connect": schema for section templates.

Arguments

• section_id - The ID of the parent operation (e.g. ID of the section) that is exposing an output to its siblings.
• output_id - The ID of the exposed output that is being provided by the section. E.g. siblings of the section will refer to the redirected output by { section_id: output_id }.
• sibling_id - The sibling of the section that should receive the output.

Trait Implementations

impl<'a, 'c, 'w, 's, 'b> Debug for DiagramContext<'a, 'c, 'w, 's, 'b>

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

Formats the value using the given formatter.