# ADR-005: Data-Driven Indicator System

## Status
Accepted

## Context
Previously, the technical indicator configurations, including their parameters and UI generation logic, were partially hardcoded within Python files (e.g., `dashboard/components/indicator_modal.py`, `dashboard/callbacks/indicators.py`). This approach made adding new indicators, modifying existing ones, or updating their parameter schemas a cumbersome process, requiring direct code modifications in multiple files.

The need arose for a more flexible, scalable, and maintainable system that allows for easier management and extension of technical indicators without requiring constant code deployments.

## Decision
We will refactor the technical indicator system to be fully data-driven. This involves:

1.  **Centralizing Indicator Definitions**: Moving indicator metadata, default parameters, and parameter schemas into JSON template files located in `config/indicators/templates/`.
2.  **Dynamic UI Generation**: The `dashboard/components/indicator_modal.py` component will dynamically read these JSON templates to generate parameter input fields for the indicator modal, eliminating hardcoded UI elements.
3.  **Dynamic Callback Handling**: The `dashboard/callbacks/indicators.py` callbacks will be refactored to dynamically collect, set, and reset indicator parameters based on the schema defined in the JSON templates, removing hardcoded logic for each indicator type.
4.  **Runtime Loading**: A new utility (`config/indicators/config_utils.py`) will be responsible for loading and parsing these JSON templates at runtime.

## Consequences

### Positive

-   **Increased Extensibility**: Adding new indicators or modifying existing ones now primarily involves creating or updating a JSON file, significantly reducing the development overhead and time to market for new indicator support.
-   **Improved Maintainability**: Centralized, data-driven configurations reduce code duplication and simplify updates, as changes are made in one place (the JSON template) rather than across multiple Python files.
-   **Reduced Code Complexity**: The `indicator_modal.py` and `indicators.py` files are now more concise and generic, focusing on dynamic generation rather than specific indicator logic.
-   **Enhanced Scalability**: The system can easily scale to support a large number of indicators without a proportional increase in Python code complexity.
-   **Better Separation of Concerns**: UI presentation logic is decoupled from indicator definition and business logic.

### Negative

-   **Initial Refactoring Effort**: Requires a significant refactoring effort to migrate existing indicators and update dependent components.
-   **New File Type Introduction**: Introduces JSON files as a new configuration format, requiring developers to understand its structure.
-   **Runtime Overhead (Minor)**: Small overhead for loading and parsing JSON files at application startup, though this is negligible for typical application sizes.
-   **Debugging Configuration Issues**: Issues with JSON formatting or schema mismatches may require checking JSON files in addition to Python code.

## Alternatives Considered

-   **Keeping Hardcoded Logic**: Rejected due to the high maintenance burden and lack of scalability.
-   **Database-Driven Configuration**: Considered storing indicator configurations in a database. Rejected for initial implementation due to added complexity of database schema management, migration, and the overhead of a full CRUD API for configurations, which was deemed unnecessary for the current scope. JSON files provide a simpler, file-based persistence model that meets the immediate needs.
-   **YAML/TOML Configuration**: Considered other configuration formats like YAML or TOML. JSON was chosen due to its widespread use in web contexts (Dash/Plotly integration) and native Python support.

## Decision Makers
[Your Name/Team Lead]

## Date
2024-06-12