[home]

The Developer's Diary

The Passive View: Crafting the UI in main_window.py

We've reached the part of the app our users will actually see. Let's make sure it's as clean as the code behind it.

Our architectural tour has brought us from the application's core to its outermost layer: the user interface. This is where all our carefully separated components—models, services, and repositories—come together to present a useful tool to our end-user, the psychologist. The main file for this layer is app/ui/main_window.py.

The Dangers of the "God Object"

In application development, it's dangerously easy for the main UI class to become a "God Object"—a monstrous, all-knowing class that handles everything from button clicks to database queries. This is a direct path to code that is impossible to test, debug, or maintain.

Novice Coder (NC): "My main window class is my masterpiece! It's 1000 lines long, it has all the button click handlers, all the SQL queries, all the logic. It's a glorious god object!"

Experienced Coder (IC): (Sighs) "And it's completely untestable and impossible to maintain. We want a Passive View. The UI should be as dumb as possible. Its only jobs are to display data and emit signals when the user does something. A save_button.clicked signal should be connected to a method that does one thing: call the appropriate method on the service layer, passing in the data from the input fields. It should never, ever contain business or persistence logic. This allows us to test our entire application without ever instantiating a single UI widget."

The principle of a Passive View is paramount. The UI's responsibility is strictly limited to presentation and input capturing. It knows how to draw a button, but it doesn't know what that button *does*. It just announces, "Hey, this button was clicked!" and passes the relevant information to the service layer to handle the rest.

Our Hypothetical main_window.py

For our SpLD app, the `MainWindow` will be initialized with a `HistoryService` instance (remember Dependency Injection from our `main.py` post?). It will contain the UI widgets and connect their signals to methods that delegate work to the service.

# app/ui/main_window.py

from PyQt6.QtWidgets import QMainWindow, QPushButton, QLineEdit, QVBoxLayout, QWidget
from ..core.services import HistoryService
from datetime import date

class MainWindow(QMainWindow):
    """
    The main window of the application (The View).
    It is a 'Passive View' that delegates all logic to the service layer.
    """
    def __init__(self, history_service: HistoryService):
        super().__init__()
        self.history_service = history_service

        self.setWindowTitle("SpLD History Taker")

        # --- UI Widget Setup ---
        # In a real app, this might be loaded from a .ui file
        self.client_id_input = QLineEdit()
        self.client_id_input.setPlaceholderText("Client ID (e.g., 1)")
        
        self.hypothesis_input = QLineEdit()
        self.hypothesis_input.setPlaceholderText("Enter hypothesis...")

        self.save_button = QPushButton("Save New Assessment")

        # --- Layout ---
        layout = QVBoxLayout()
        layout.addWidget(self.client_id_input)
        layout.addWidget(self.hypothesis_input)
        layout.addWidget(self.save_button)

        container = QWidget()
        container.setLayout(layout)
        self.setCentralWidget(container)

        # --- Signal Connections ---
        self.save_button.clicked.connect(self.handle_save_assessment)

    def handle_save_assessment(self):
        """
        Captures user input and calls the service layer.
        Contains no business or persistence logic.
        """
        client_id = int(self.client_id_input.text())
        hypotheses = [self.hypothesis_input.text()]
        
        # Delegate the actual work to the service layer
        try:
            self.history_service.create_new_assessment(
                client_id=client_id,
                assessment_date=date.today(),
                hypotheses=hypotheses
            )
            print("Assessment saved successfully!")
            # Here we could show a success message to the user
        except Exception as e:
            print(f"An error occurred: {e}")
            # Here we could show an error dialog

Breaking it down:

• Dumb and Passive: The `MainWindow` class is intentionally simple. It creates widgets and connects a signal. It has no idea how an assessment is created or saved.
• Delegation to Service: The handle_save_assessment method is the perfect example of the Passive View pattern. It gathers the raw data from the input fields, does a basic conversion (like `int()`), and immediately passes it off to the `history_service`. The UI doesn't validate the data or interact with the database.
• Clear Separation: All the complex logic for creating an `Assessment` object and saving it is handled elsewhere (in the service and repository). This makes the UI code easy to read and the service logic easy to test independently.
• Testability: Because the view is so simple, we can test our `HistoryService` thoroughly by just calling its methods directly, without ever needing to create a `QMainWindow` or simulate button clicks. This makes our tests faster and more reliable.

We have now completed our architectural skeleton. From the entry point in `main.py` to the user-facing `main_window.py`, each file has a distinct and well-defined purpose. This clean separation is the key to building a robust, maintainable, and scalable application.