Skip to content

Configuration System

levi edited this page Nov 6, 2025 · 2 revisions

Configuration System

Table of Contents

  1. Indicator Configuration System Overview
  2. IndicatorConfig Class Implementation
  3. InputDefinition Class Details
  4. StyleDefinition Class Details
  5. Configuration Lifecycle Management
  6. Serialization and UI Integration
  7. False Breakout Indicator Example
  8. Common Issues and Solutions
  9. Performance Considerations

Indicator Configuration System Overview

The indicator configuration system provides a comprehensive framework for managing indicator settings, supporting complex input parameter definitions, style configurations, runtime modifications, automatic UI generation, and robust validation and serialization capabilities. The system is built around the IndicatorConfig class, which serves as the central configuration container for trading indicators.

IndicatorConfig Class Implementation

The IndicatorConfig class serves as the foundation for indicator configuration, encapsulating all essential properties and methods for managing indicator settings. It includes basic information fields such as name, version, description, and author, along with status flags like enabled and debug. The class maintains collections of input parameters and style definitions, enabling comprehensive configuration management.

Key attributes include:

  • name: The indicator's name (default: "CustomIndicator")
  • version: Version string (default: "1.0.0")
  • description: Brief description of the indicator's purpose
  • author: Creator information
  • enabled: Status flag indicating if the indicator is active
  • debug: Flag for enabling debug mode
  • inputs: List of InputDefinition objects for parameter configuration
  • styles: List of StyleDefinition objects for visual styling
  • on_config_changed: Optional callback function triggered when configuration changes

The class provides methods for retrieving and modifying configuration values, with built-in validation and error handling to ensure data integrity.

InputDefinition Class Details

The InputDefinition class defines the characteristics of individual input parameters for indicators. Each input parameter has a unique identifier (id), display name, type, default value, and current value. The class supports various input types through the InputType enumeration, including INTEGER, FLOAT, BOOLEAN, STRING, COLOR, OPTIONS, and SOURCE.

Additional properties include:

  • tooltip: Descriptive text for user guidance
  • options: List of InputOption objects for dropdown selections
  • min_value and max_value: Range constraints for numeric inputs
  • step: Increment value for numeric inputs
  • visible: Flag controlling UI visibility
  • group: Categorization for organizing inputs in the UI

The class includes validation logic to ensure input values meet type-specific requirements and constraints. For example, color inputs must be valid hex color strings, and option inputs must have values matching one of the defined options.

StyleDefinition Class Details

The StyleDefinition class manages visual styling properties for indicator elements. Each style definition includes an identifier (id), display name, and various visual attributes. The supported styling properties include:

  • color: Hex color string for the element's color
  • line_width: Width of lines (0-10)
  • line_style: Line pattern (0=solid, 1=dashed, 2=dotted)
  • transparency: Opacity level (0-100)
  • visible: Visibility flag
  • group: Category for UI organization

The class implements validation to ensure all style properties are within acceptable ranges. For instance, line width must be between 0 and 10, line style must be 0, 1, or 2, and transparency must be between 0 and 100. Color values must be valid hex strings starting with '#'.

classDiagram
class StyleDefinition {
+string id
+string display_name
+string color
+int line_width
+int line_style
+int transparency
+bool visible
+string group
+validate() bool
+to_dict() dict
}
Loading

Configuration Lifecycle Management

The configuration system provides a complete lifecycle for managing indicator settings, from initial setup to runtime modifications. The get_config() method in the TVIndicator base class returns the indicator's configuration object, serving as the entry point for configuration access.

Runtime updates are handled through several methods:

  • set_input_value(): Updates a single input parameter with validation and callback support
  • set_input_values(): Batch updates multiple input parameters
  • update_style(): Modifies style properties with validation and change notification
  • reset_to_defaults(): Restores all input parameters to their default values

The system implements a transactional approach to configuration changes, temporarily storing old values during updates. If validation fails or a callback error occurs, the system automatically reverts to the previous values, ensuring configuration integrity. The on_config_changed callback is triggered after successful updates, enabling real-time response to configuration changes.

sequenceDiagram
participant User as "User Interface"
participant Config as "IndicatorConfig"
participant Callback as "on_config_changed"
User->>Config : set_input_value("period", 20)
Config->>Config : Validate new value
alt Validation successful
Config->>Config : Update parameter
Config->>Callback : Trigger callback with changes
alt Callback successful
Config-->>User : Return success
else Callback failed
Config->>Config : Restore old value
Config-->>User : Return error
end
else Validation failed
Config->>Config : Keep old value
Config-->>User : Return validation error
end
Loading

Serialization and UI Integration

The configuration system includes comprehensive serialization methods for persisting and transmitting configuration data. The to_dict() method converts the entire configuration to a dictionary format suitable for JSON serialization, while to_json() provides a direct JSON string representation with configurable indentation.

Deserialization is handled by from_dict() and from_json() methods, which restore configuration from dictionary or JSON string data. These methods update basic information, input parameter values, and style properties while maintaining validation and error handling.

The serialized format includes:

  • Basic indicator information (name, version, description, author)
  • Status flags (enabled, debug)
  • Input parameters with their current values
  • Style definitions with all visual properties

This serialization capability enables seamless UI integration, allowing configuration data to be easily transmitted between the backend and frontend components of the trading application.

flowchart TD
A["Configuration Object"] --> B["to_dict()"]
B --> C["Dictionary Structure"]
C --> D["to_json()"]
D --> E["JSON String"]
E --> F["UI/Storage"]
F --> G["from_json()"]
G --> H["Dictionary"]
H --> I["from_dict()"]
I --> J["Restored Configuration"]
Loading

False Breakout Indicator Example

The false breakout indicator demonstrates a complex configuration with multiple input groups and style definitions. This indicator detects false breakout patterns where price breaks to a new high/low and quickly reverses. The configuration includes:

  • Main Settings group with parameters for false breakout period, minimum period, and signal validity period
  • Advanced Smoothing group with options for smoothing type (Diamond, WMA, HMA), smoothing length, and aggressive mode
  • Signals group with style definitions for upward and downward false breakout signals

The input parameters use various types, including INTEGER for numeric values, OPTIONS for the smoothing type dropdown, and BOOLEAN for the aggressive mode toggle. The style definitions specify colors, line widths, and other visual properties for the indicator's plotted elements.

This example showcases the configuration system's ability to organize parameters into logical groups, support different input types, and manage complex styling requirements for sophisticated trading indicators.

Common Issues and Solutions

Several common issues can arise when working with the configuration system, along with their solutions:

Configuration Validation Failures: These occur when input values violate type or range constraints. The system prevents invalid configurations by validating values before applying changes and reverting to previous values if validation fails. Developers should ensure proper input validation in their UI components and provide clear error messages to users.

Improper Callback Handling: Callback functions may throw exceptions during execution. The configuration system handles this by catching exceptions and reverting to previous values, preventing configuration corruption. Developers should implement robust error handling in their callback functions and avoid long-running operations that could block the main thread.

Race Conditions in Multi-threaded Environments: When multiple components modify configuration simultaneously, race conditions can occur. The solution is to implement proper synchronization mechanisms and ensure atomic updates to configuration properties.

Performance Issues with Frequent Updates: Excessive configuration updates can impact performance. The recommended solution is to batch updates when possible and implement debouncing for UI-driven changes.

Performance Considerations

When managing configuration updates in real-time scenarios, several performance considerations are important:

Update Frequency: Frequent configuration changes can impact system performance, especially when callbacks trigger recalculations or UI updates. Implementing debouncing or throttling mechanisms can help reduce the update frequency while maintaining responsiveness.

Batch Operations: When multiple configuration changes are needed, using batch methods like set_input_values() is more efficient than individual updates, as it reduces the number of validation checks and callback invocations.

Callback Optimization: Callback functions should be lightweight and avoid blocking operations. For complex processing, consider using asynchronous execution or background threads to prevent UI freezing.

Memory Management: The configuration system creates temporary objects during updates (e.g., old value storage). In high-frequency update scenarios, this can lead to increased memory usage and garbage collection pressure. Implementing object pooling or reusing objects can help mitigate this issue.

Network Considerations: When configuration updates are transmitted over a network, the serialized data size should be minimized. Using efficient serialization formats and compressing data when appropriate can reduce bandwidth usage and improve response times.

Clone this wiki locally