# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a JavaServer Faces (JSF) webview layer within the `eo.web` module. It provides the backing beans, view logic, and JSP view bindings that serve specific ACA001-related user-facing pages in the application. This module sits at the presentation tier — it receives HTTP requests, delegates to backing beans for data, and renders JSP views to the browser.

The module is structured as a flat package with one child subpackage (`ACA001SF`), which encapsulates all the classes and configuration related to the ACA001 view flow. This appears to be a JSF-based MVC setup where `faces-config.xml` and several XML-based configuration files wire together beans, logic classes, and JSP views.

## Sub-module Guide

### ACA001SF

The `ACA001SF` subpackage is the sole child of `eo.web.webview`. It provides the complete view logic for a single ACA001-related JSP view, following the standard JSF MVC pattern.

**Core classes:**

- **`ACA001SFBean`** — A JSF backing bean with a single `value` property (getter only). This bean is the data carrier between logic and view. The absence of a setter indicates the value is set internally and read-only from the JSP perspective, typically via a JSF expression like `#{aca001sfBean.value}`.

- **`ACA001SFLogic`** — A view logic controller class with an `execute()` method. Currently the method body is empty, suggesting this class is a scaffold or placeholder for business logic associated with the ACA001 "Futurity" view flow.

**Configuration wiring:**

These classes are wired through multiple XML configuration files:
- `faces-config.xml` — standard JSF managed bean registration for `ACA001SFBean`
- `WEBGAMEN_FULL_ACA001.xml` — references both the bean and logic
- `WEBGAMEN_ACA001010PJP.xml` — references both the bean and logic
- `x33S_ACA001.xml` — references both the bean and logic
- `FULL_ACA001010PJP.jsp` — the actual JSP view that binds to the bean
- `external-refs.xml` — references the logic class

**Request flow:**

1. A request arrives targeting the ACA001 view (e.g., `FULL_ACA001010PJP.jsp`).
2. JSF resolves `ACA001SFBean` from `faces-config.xml` or the `WEBGAMEN` XML configs.
3. `ACA001SFLogic.execute()` is invoked as the view's logic entry point.
4. The JSP reads `ACA001SFBean.getValue()` to render the page.

**Source tree notes:**

`ACA001SFLogic` exists in two source trees (`full-fixture-codebase` and `xml-unresolved-fqn`), suggesting a mirror or resolution mechanism used by a build or documentation pipeline. One appears canonical; changes may need to be propagated.

## Key Patterns and Architecture

### JSF MVC Pattern

The entire `webview` package follows the classic JSF MVC pattern:

```
Request → Faces Config → Bean → JSP View
                    ↘ Logic →/
```

The bean holds state (a single `value` string), the logic class provides the controller hook, and the JSP renders the UI by binding to the bean's properties.

### Configuration-Driven Wiring

Rather than using annotations (e.g., `@ManagedBean`), the wiring here is XML-driven. Multiple configuration files reference the same bean and logic classes, which suggests a layered or modular configuration approach where different XML configs might activate under different conditions or deployment profiles.

### Minimal Data Model

The data model in this module is intentionally light — a single string property. There are no entities, DTOs, or domain objects defined at the webview layer. This is consistent with JSF best practices where the webview should be thin and delegate to service layers (which may live in other packages not indexed here).

### Two Source Trees

The presence of `ACA001SFLogic` in both `full-fixture-codebase` and `xml-unresolved-fqn` suggests a dual-tree build system, possibly for separating production fixtures from test or documentation artifacts. Developers should be aware of which tree they are editing.

## Diagram: ACA001SF Component Architecture

The following diagram shows how the components within the `ACA001SF` subpackage relate:

```mermaid
flowchart TD
    subgraph webview["Eo / Web / Webview Package"]
        ACA001SF["ACA001SF Subpackage"]
    end
    subgraph subpackages["Child Sub-packages"]
        ACA001SF
    end
    subgraph components["ACA001SF Components"]
        Bean["ACA001SFBean"]
        Logic["ACA001SFLogic"]
        View["FULL_ACA001010PJP.jsp"]
    end
    subgraph config["Configuration"]
        Faces["faces-config.xml"]
        WebGameN1["WEBGAMEN_FULL_ACA001.xml"]
        WebGameN2["WEBGAMEN_ACA001010PJP.xml"]
        X33S["x33S_ACA001.xml"]
        ExtRefs["external-refs.xml"]
    end
    Bean -->|provides| View
    Logic -->|executes| View
    Faces -->|registers| Bean
    WebGameN1 -->|wires| Bean
    WebGameN1 -->|wires| Logic
    WebGameN2 -->|wires| Bean
    WebGameN2 -->|wires| Logic
    X33S -->|wires| Bean
    X33S -->|wires| Logic
    ExtRefs -->|references| Logic
    webview -->|contains| subpackages
```

## Dependencies and Integration

### Outbound Dependencies

This package declares no internal package dependencies — it does not import or reference any other classes from within the `eo.web` hierarchy. The sole outbound dependency is the JSF framework itself, which resolves bean registrations and manages the request lifecycle.

### Inbound Dependencies (who consumes this module)

The module is a leaf in the `eo.web.webview` package hierarchy. Its components are consumed by:

| 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 source files or classes outside this package were detected as importing from `eo.web.webview`, though XML configs may be read at runtime by the JSF container.

## Notes for Developers

- **Empty logic method:** `ACA001SFLogic.execute()` currently has an empty body. If you are extending this module, this is the method where view-side business logic should be implemented. The Javadoc in the canonical source tree describes it as "Futurity view logic."

- **Immutable bean property:** `ACA001SFBean` exposes only a getter for `value` — there is no setter. If you need to set the value from outside (e.g., from `ACA001SFLogic`), add a corresponding `setValue(String)` method.

- **JSF naming convention:** The bean name likely maps to a JSF expression like `#{aca001sfBean}` (lowercase first letter, camelCase). This convention is controlled by the JSF configuration in `faces-config.xml`. Verify the exact managed-bean-name in that file 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. When editing, be aware of which source tree you are modifying and whether changes need to be propagated to the other.

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

- **No child subpackages:** The `ACA001SF` subpackage is the only child. Any new ACA-related views should be added as sibling subpackages within `eo.web.webview` following the same naming and structure pattern.