# Eo

## Overview

The `eo` package serves as a top-level application root in a Java-based web application, most notably hosting the `eo.web` module. `eo.web` is the **presentation layer** of the application, built on **JavaServer Faces (JSF)** and responsible for serving user-facing pages, handling HTTP requests, and rendering JSP views to browsers. It follows the classic JSF MVC pattern where backing beans hold state, logic classes act as controllers, and JSP views bind to bean properties for rendering.

At the time of analysis, `eo.web` is a focused module with a single feature surface — the ACA001 ("Futurity") view flow — implemented inside `eo.web.webview.ACA001SF`. The module is intentionally thin at the web tier, exposing minimal data structures and delegating domain logic to service layers that may reside in packages outside the current documentation scope.

## Sub-module Guide

`eo` currently has one documented child module:

### eo.web — The Presentation Tier

`eo.web` is the user-facing layer of the application. It exposes its capabilities through a single subpackage:

- **`eo.web.webview`** — The backing-bean and view-logic layer. This subpackage delegates the bulk of its implementation to its child subpackages, organizing feature-specific logic under a shared JSF framework context.
- **`eo.web.webview.ACA001SF`** — The "Futurity" view flow. It comprises three components working in concert:
  - **`ACA001SFBean`** — A thin JSF backing bean exposing a single read-only `value` property. Acts as the data bridge between controller logic and the JSP view.
  - **`ACA001SFLogic`** — The controller class with an `execute()` method. Currently a scaffold awaiting implementation, it is the designated entry point for view-side business logic.
  - **`FULL_ACA001010PJP.jsp`** — The JSP view that binds to the bean's properties to render the page.

These components are wired together through **XML configuration files** (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `external-refs.xml`) rather than annotation-based registration. This configuration-driven approach decouples the wiring from the source code and allows it to potentially vary across deployment profiles or activation conditions.

The relationship between `webview` and `ACA001SF` is one of **containment and delegation**. `webview` provides the JSF framework context; `ACA001SF` provides the actual feature-specific logic. Any future views would follow the same pattern — a sibling subpackage within `webview`, each with its own bean, logic, and view files, all wired through the shared XML configuration infrastructure.

## Key Patterns and Architecture

### JSF MVC with XML-Driven Wiring

The `eo.web` module follows the classic JSF model-view-controller triad with a notable distinction: bean registration is entirely **XML-driven** rather than annotation-based (e.g., no `@ManagedBean`). Multiple configuration files reference the same bean and logic classes, suggesting a modular or profile-based configuration strategy.

This design has a trade-off:
- **Strength**: Configuration can be adjusted without source code changes, enabling deployment-profile customization.
- **Risk**: Refactoring or renaming classes requires auditing all XML config files to avoid broken runtime references.

### Thin Data Model

The data model at the webview layer is intentionally minimal. `ACA001SFBean` exposes only a single string property with no entities, DTOs, or domain objects defined at this layer. This is consistent with JSF best practices where the web tier should be thin and delegate domain logic to service layers.

### Dual Source Tree Architecture

`ACA001SFLogic` exists in two source trees — `full-fixture-codebase` and `xml-unresolved-fqn` — suggesting a dual-tree build or documentation pipeline. One tree appears canonical; changes in one may need propagation to the other. Developers working in this area should verify which tree they are editing.

## Request Flow

When a request targets an ACA001 view, the execution flow proceeds as follows:

1. The JSF container resolves the target JSP (e.g., `FULL_ACA001010PJP.jsp`).
2. `faces-config.xml` and the `WEBGAMEN` XML configs wire `ACA001SFBean` into request scope.
3. `ACA001SFLogic.execute()` is invoked as the controller entry point.
4. The JSP binds to `ACA001SFBean.getValue()` to render the page to the user.

## Diagram: Module Interaction

The following diagram illustrates how the components within `eo.web` interact:

```mermaid
flowchart TD
    subgraph web["Eo / Web Module"]
        web_pkg["eo.web Package"]
    end
    subgraph webview["Webview Package"]
        webview_pkg["eo.web.webview"]
    end
    subgraph feature["ACA001SF Subpackage"]
        bean["ACA001SFBean"]
        logic["ACA001SFLogic"]
        view["FULL_ACA001010PJP.jsp"]
    end
    subgraph config["Configuration Layer"]
        faces["faces-config.xml"]
        webg1["WEBGAMEN_FULL_ACA001.xml"]
        webg2["WEBGAMEN_ACA001010PJP.xml"]
        x33s["x33S_ACA001.xml"]
        ext["external-refs.xml"]
    end
    bean -->|provides| view
    logic -->|executes| view
    faces -->|registers| bean
    webg1 -->|wires| bean
    webg1 -->|wires| logic
    webg2 -->|wires| bean
    webg2 -->|wires| logic
    x33s -->|wires| bean
    x33s -->|wires| logic
    ext -->|references| logic
    web -->|contains| webview
    webview -->|contains| feature
    feature -->|comprises| bean
    feature -->|comprises| logic
    feature -->|comprises| view
```

## Dependencies and Integration

### Outbound Dependencies

The `webview` package declares no internal package dependencies within the `eo` hierarchy — it does not import or reference other classes in sibling or parent packages. Its sole external framework dependency is the **JSF runtime**, which resolves bean registrations and manages the request lifecycle at runtime.

### Inbound Dependencies

This module is a leaf in the `eo` package hierarchy. Its components are consumed through XML configuration files rather than direct source-level imports. The following files reference the web layer at runtime:

| Consumer | References |
|----------|-----------|
| `faces-config.xml` | `ACA001SFBean` registration |
| `WEBGAMEN_FULL_ACA001.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `WEBGAMEN_ACA001010PJP.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `x33S_ACA001.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `FULL_ACA001010PJP.jsp` | `ACA001SFBean`, `ACA001SFLogic` view binding |
| `external-refs.xml` | `ACA001SFLogic` reference |

No other source files outside this package were detected as importing from `eo.web.webview`, though the XML configs are read by the JSF container at runtime to wire the beans.

## Notes for Developers

- **Empty logic method**: `ACA001SFLogic.execute()` currently has an empty body. The Javadoc in the canonical source tree describes this as "Futurity view logic" — this is where view-side business logic should be implemented when ready.

- **Immutable bean property**: `ACA001SFBean` exposes only a getter for `value`. If you need to set this value from outside the bean (e.g., from `ACA001SFLogic`), a `setValue(String)` method will need to be added.

- **JSF naming convention**: The bean name maps to a JSF expression like `#{aca001sfBean}` (lowercase first letter, camelCase). Verify the exact managed-bean-name in `faces-config.xml` if the expression does not resolve.

- **Multiple source tree presence**: `ACA001SFLogic` exists in both `full-fixture-codebase` and `xml-unresolved-fqn`. These may be synchronized artifacts from different build configurations. Changes in one tree may need to be propagated to the other.

- **XML configuration density**: Four `WEBGAMEN`/`x33S` XML config files plus `faces-config.xml` and `external-refs.xml` reference the same two classes. Before refactoring or renaming, audit all of these files to avoid broken runtime references.

- **No child subpackages beyond ACA001SF**: The `ACA001SF` subpackage is the only documented child. Any new views should be added as sibling subpackages within `eo.web.webview` following the same structure: a bean class, a logic class, JSP views, and corresponding XML configuration entries.