# Eo

## Overview

The `eo` package serves as the top-level container for the EO application's presentation layer. It does not own business logic directly — instead, it acts as the bridge between the application's business / service layer and the end user. The package accepts user requests, delegates to logic handlers that fetch or compute data, and renders results through JavaServer Faces (JSF) backed views.

This area of the codebase appears to target an older JSF lifecycle model (1.x or early 2.x), relying on XML-based bean registration in `faces-config.xml` rather than annotation-driven configuration. New components added here follow the traditional XML wiring pattern.

## Sub-module Guide

### Web (`eo.web`)

The `eo.web` package is the web presentation layer of the EO application. It provides the user-facing surface of the system, rendering data to users through JSF-backed views. Rather than owning business logic itself, it delegates to logic handlers and renders results via JSP views.

Within `eo.web` sits the `webview` sub-package — currently a lightweight JSF MVC scaffold centered on one view module: `ACA001SF`. This module consists of two classes:

- **`ACA001SFBean`** — A JSF backing bean holding a single `String value` property. With only a getter (no setter), the value is populated programmatically by the logic class rather than bound to user input.
- **`ACA001SFLogic`** — A logic handler whose `execute()` method is the entry point for the view. The method body is currently empty, marking this as a stub awaiting business logic implementation. The Javadoc labels it as "Futurity view logic," indicating it is intended to display forward-looking or anticipated-state data once fully developed.

Despite its minimal implementation, `ACA001SF` is already wired into the broader application through multiple configuration files (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`) and at least one JSP view (`FULL_ACA001010PJP.jsp`).

The `webview` sub-module and the broader `eo.web` package form a cohesive MVC chain: the logic handler prepares data, the backing bean exposes it, and the JSP view renders it via EL. Future business logic will be added into `ACA001SFLogic.execute()` and written to the bean for rendering.

Note that `ACA001SFLogic` exists in two codebase variants (`full-fixture-codebase` and `xml-unresolved-fqn`), likely representing different build configurations or fixture sets. The full-fixture version carries the Javadoc comment; the other does not. These should be treated as different fixture configurations rather than divergent implementations.

## Key Patterns and Architecture

### JSF MVC Pattern

The `eo.web` package follows a uniform two-class MVC pattern:

```
[Backing Bean] <--> [Logic Handler]
       ^                    |
       |                    | prepares data
       |                    v
       +---- JSP View <----+
```

The backing bean is the model object visible to the view. The logic handler serves as the controller, fetching or computing data and writing it to the bean. The JSP (or Facelet) view renders the bean's properties via JSF Expression Language (EL).

### Configuration-Driven Wiring

Bean registration and view wiring are managed entirely through external XML descriptors (`faces-config.xml` and supplemental `WEBGAMEN_*`, `x33S_*` files). This keeps the bean classes as lightweight POJOs without annotation-heavy configuration, consistent with a traditional JSF 1.x / early JSF 2.x deployment model.

### Stub-First Development

The empty `execute()` body and the absence of a setter on the bean's `value` field suggest a stub-first development approach: the structural scaffolding is laid out and wired into the JSF lifecycle first, with the expectation that business logic will be integrated later. This pattern means that any developer extending this module should treat the existing classes as scaffolding rather than production-ready logic.

### Data Flow

The current data model is intentionally simple — a single `String` field flowing from the logic class into the bean and then into the view. Future extensions will need to introduce more complex data structures into `ACA001SFLogic.execute()`, at which point the backing bean and view bindings will also need to evolve to support them.

## Module Interaction Diagram

The following diagram shows how the `webview` sub-module sits within `eo.web`, which is the sole top-level package under `eo`:

```mermaid
flowchart TD
    subgraph eo_package["eo Package"]
        eo_web["eo.web
Web presentation layer"]

        subgraph eo_web_detail["eo.web Internal"]
            Webview["eo.web.webview
JSF MVC presentation scaffold"]
        end
    end

    subgraph Webview_Internal["Webview Internal Structure"]
        Bean["ACA001SFBean
backing bean"]
        Logic["ACA001SFLogic
view logic handler"]
        Views["JSP views
FULL_ACA001010PJP.jsp"]
        Configs["XML configs
faces-config.xml, WEBGAMEN_*.xml, x33S_*.xml"]
    end

    eo_web --> Webview
    Webview --> Bean
    Webview --> Logic
    Logic -->|"prepares data"| Bean
    Bean -->|"renders via EL"| Views
    Logic -->|"managed by"| Configs
```

## Dependencies and Integration

### Incoming Dependencies

The `webview` module is consumed by several configuration and view files that define its place in the application:

| Consumer | Uses |
|----------|------|
| `faces-config.xml` | `ACA001SFBean` (managed bean registration) |
| `WEBGAMEN_FULL_ACA001.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `WEBGAMEN_ACA001010PJP.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `x33S_ACA001.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `FULL_ACA001010PJP.jsp` | `ACA001SFBean`, `ACA001SFLogic` |
| `external-refs.xml` | `ACA001SFLogic` |

### Framework Dependencies

This module depends on the JSF runtime and standard JavaBeans conventions. It does not import any external application packages, meaning it is a pure presentation-layer component. Business logic integration would occur inside `ACA001SFLogic.execute()`, where service-layer calls or data-access queries would be added to prepare data for the view.

### Extension Points

When implementing the futurity logic, the intended extension point is `ACA001SFLogic.execute()`. This is where business service calls or data-access logic should be added, with results written to the bean's `value` field for rendering in the JSP view. If the data model needs to grow beyond a single `String`, both the bean (adding a setter and additional properties) and the view bindings will need to be updated accordingly.

## Notes for Developers

- **Stub implementation:** The current logic class has an empty `execute()` method. If you are working in the `full-fixture-codebase`, check sibling modules or parent services for actual business logic that may need to be wired into this view layer.
- **Two codebase variants:** `ACA001SFLogic` exists in both `full-fixture-codebase` and `xml-unresolved-fqn` paths. The full-fixture version includes a Javadoc comment ("Futurity view logic") absent from the other. Treat these as different fixture configurations rather than divergent implementations.
- **Bean naming:** The class `ACA001SFBean` follows the JSF convention of suffixing managed beans with `Bean`. The default EL name would be the uncapitalized form (e.g., `aca001sFBean`). Verify the exact name by checking `faces-config.xml`, as XML declarations can override the default.
- **No setter on value:** The bean exposes only a getter. If user-facing input binding is needed in the future, a setter (`setValue(String)`) must be added.
- **Extension point:** When implementing the futurity logic, `ACA001SFLogic.execute()` is the intended extension point. Add business service calls or data-access logic here, and write results to the bean's `value` field for rendering in the JSP view.
- **JSF version context:** The reliance on `faces-config.xml` for bean registration (rather than `@ManagedBean` or `@Named` annotations) suggests this codebase targets an older JSF version (1.x or early 2.x). When adding new components, consider whether annotation-based configuration is available or if XML wiring is still required.