# Eo / Web

## Overview

The `eo.web` module is the presentation layer of the application, built on JavaServer Faces (JSF). It is responsible for serving user-facing web pages, handling HTTP requests, and rendering JSP views to browsers. The module 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.

The module is a top-level component under the root `eo` parent package. Its primary (and currently sole) subpackage is `eo.web.webview`, which encapsulates the webview layer — the backing beans, view logic, and JSP view bindings that power ACA001-related user-facing pages.

## Sub-module Guide

### eo.web.webview

The `webview` subpackage is the core of `eo.web`. It provides the JSF backing beans, logic controllers, and JSP views for the application's presentation tier. Rather than organizing by feature or user flow at the top level, `webview` delegates the bulk of its implementation to its child subpackages.

#### ACA001SF

The `ACA001SF` subpackage is the only child of `webview`, and it contains the complete view logic for the ACA001 ("Futurity") view flow. It follows the standard three-component JSF pattern:

- **ACA001SFBean** — a JSF backing bean with a single read-only `value` property. It acts as the data bridge between logic and the JSP view, exposed to views via expressions like `#{aca001sfBean.value}`.
- **ACA001SFLogic** — the controller class with an `execute()` method. This is the entry point where view-side business logic is (or should be) implemented. Currently the method body is empty, suggesting this is a scaffold awaiting implementation.
- **FULL_ACA001010PJP.jsp** — the JSP view that renders the page by binding to the bean's properties.

These three components are wired together not by annotations, but through a cluster of XML configuration files (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `external-refs.xml`). This configuration-driven approach means the wiring is decoupled from the source code and can potentially vary across deployment profiles or activation conditions.

#### How the sub-modules work together

The relationship between `webview` and `ACA001SF` is one of containment and delegation. `webview` provides the JSF framework context and serves as the package namespace; `ACA001SF` provides the actual feature-specific logic. If additional ACA views or unrelated views are added in the future, they 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 architecture follows the classic JSF model-view-controller triad, but with an important distinction: rather than relying on annotation-based bean registration (e.g., `@ManagedBean`), the wiring is entirely XML-driven. Multiple configuration files reference the same bean and logic classes, suggesting a modular or profile-based configuration strategy. This is both a strength and a risk — it allows configuration to be adjusted without code changes, but it also means refactoring or renaming requires auditing all XML files.

### 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, which may reside in packages not yet indexed in this documentation.

### 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 be aware of which tree they are editing.

## Request Flow

When a request targets an ACA001 view, the flow is:

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 the request scope.
3. `ACA001SFLogic.execute()` is invoked as the controller entry point.
4. The JSP binds to `ACA001SFBean.getValue()` to render the page.

## Diagram: Module Structure

The following diagram shows how the `eo.web` module and its sub-packages relate:

```mermaid
flowchart TD
    subgraph web["Eo / Web Module"]
        web_inner["eo.web Package"]
    end
    subgraph webview_pkg["Webview Package"]
        webview_inner["eo.web.webview"]
    end
    subgraph child["Child Sub-packages"]
        ACA001SF["ACA001SF Subpackage"]
    end
    subgraph components["ACA001SF Components"]
        Bean["ACA001SFBean"]
        Logic["ACA001SFLogic"]
        View["FULL_ACA001010PJP.jsp"]
    end
    subgraph config["Configuration Files"]
        Faces["faces-config.xml"]
        WebGame1["WEBGAMEN_FULL_ACA001.xml"]
        WebGame2["WEBGAMEN_ACA001010PJP.xml"]
        X33S["x33S_ACA001.xml"]
        ExtRefs["external-refs.xml"]
    end
    Bean -->|provides| View
    Logic -->|executes| View
    Faces -->|registers| Bean
    WebGame1 -->|wires| Bean
    WebGame1 -->|wires| Logic
    WebGame2 -->|wires| Bean
    WebGame2 -->|wires| Logic
    X33S -->|wires| Bean
    X33S -->|wires| Logic
    ExtRefs -->|references| Logic
    web -->|contains| webview_pkg
    webview_pkg -->|contains| child
    child -->|comprises| components
```

## Dependencies and Integration

### Outbound Dependencies

The `webview` package declares no internal package dependencies — it does not import or reference other classes within the `eo` hierarchy. The sole 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.web` hierarchy. Its components are consumed through XML configuration files rather than direct source-level imports:

| Consumer | What It 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 at runtime by the JSF container 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 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.