# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a Java EE / JSF web presentation layer responsible for rendering business-focused views to end users. It follows the classic Model-View-Controller (MVC) pattern, where JSF backing beans manage view state, logic classes encapsulate view-level business processing, and JSP pages deliver the UI. Views in this package are wired together through a combination of `faces-config.xml` and dedicated XML configuration files (e.g., `WEBGAMEN_*.xml`, `x33S_*.xml`), reflecting a configuration-driven approach rather than a fully annotation-based one.

Each sub-module under `eo.web.webview` represents a single, self-contained view — a named page backed by its own bean and logic class. This creates a clean boundary between views, making it straightforward to add or remove pages without impacting unrelated functionality.

## Sub-module Guide

### ACA001SF — Futurity View

**File:** `eo/web/webview/ACA001SF/`

The `ACA001SF` sub-module implements the "Futurity" view. It consists of a backing bean (`ACA001SFBean`) that exposes a single read-only `String` field called `value`, a logic class (`ACA001SFLogic`) with a no-op `execute()` method, and a JSP view page (`FULL_ACA001010PJP.jsp`). The module is wired through four XML configuration files (`WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `faces-config.xml`) plus an external reference config.

This view appears to be a placeholder or scaffolding — the logic layer has no implementation, and the bean carries no state beyond a single string. The "Futurity" label in the Javadoc suggests this page belongs to a specific business domain, but its current form is more a template awaiting data-loading and interaction logic.

All sub-modules follow the same structural pattern:

- **Backing bean** — A POJO managed by JSF, exposing properties the JSP page reads via EL.
- **Logic class** — A dedicated class containing the `execute()` method that the bean or framework invokes during the JSF lifecycle.
- **JSP view page** — The rendered UI that binds to the bean and logic class through EL expressions.
- **XML configuration** — Multiple XML files manage managed-bean registration, action mappings, and external wiring.

## How the Sub-modules Work Together

Each view operates as an independent unit within the JSF request lifecycle. Requests are dispatched to a specific view page, the associated backing bean is resolved, the JSP renders using bean properties, and user actions invoke the logic class's `execute()` method. Views do not directly communicate with one another — navigation between views is handled by JSF's navigation outcome mechanism (though current logic classes return `void`, limiting this capability).

```mermaid
flowchart TD
    subgraph Views["Views (JSP Pages)"]
        J1["FULL_ACA001010PJP.jsp"]
        J2["..."]
    end

    subgraph Beans["Backing Beans"]
        B1["ACA001SFBean"]
        B2["..."]
    end

    subgraph Logic["View Logic"]
        L1["ACA001SFLogic"]
        L2["..."]
    end

    subgraph Config["XML Configuration"]
        C1["faces-config.xml"]
        C2["WEBGAMEN_*.xml"]
        C3["x33S_*.xml"]
        C4["external-refs.xml"]
    end

    J1 -->|EL reads| B1
    J1 -->|invokes| L1
    B1 -->|delegates| L1
    C1 -->|registers| B1
    C2 -->|maps actions| B1
    C2 -->|maps actions| L1
    C3 -->|additional config| B1
    C4 -->|wires| L1
```

## Key Patterns and Architecture

- **MVC via JSF backing beans** — Each view's bean is the "M" (model), the logic class provides the "C" (controller), and the JSP is the "V" (view). This separation keeps concerns distinct and makes each component independently testable.

- **Read-only bean properties** — Beans like `ACA001SFBean` expose getters without setters, making them suitable for display-only data. This is a deliberate pattern that prevents two-way binding from user input, channeling all data population through the logic layer.

- **No-op logic stubs** — The `execute()` methods in logic classes are current no-ops. This suggests the framework uses these as extension points — developers add business logic here when a view needs data loading, validation, or processing.

- **Configuration-driven wiring** — JSF managed beans are registered across multiple XML files rather than via annotations. This means bean lifecycle, scope, and navigation outcomes are defined externally, which can simplify centralized configuration but requires checking all relevant XML files when modifying behavior.

- **Dual source trees** — Some logic classes appear in both a "full-fixture-codebase" and an "xml-unresolved-fqn" tree, with identical signatures but varying Javadoc coverage. The canonical version is the full-fixture variant.

## Dependencies and Integration

### Inbound

The `eo.web.webview` module is consumed by the following external configuration and view artifacts:

| Artifact | Type | Sub-modules Referenced |
|---|---|---|
| `WEBGAMEN_FULL_ACA001.xml` | XML config | `ACA001SF` |
| `WEBGAMEN_ACA001010PJP.xml` | XML config | `ACA001SF` |
| `x33S_ACA001.xml` | XML config | `ACA001SF` |
| `faces-config.xml` | JSF config | `ACA001SF` |
| `FULL_ACA001010PJP.jsp` | JSP view | `ACA001SF` |
| `external-refs.xml` | External config | `ACA001SF` |

### Framework dependencies

This module depends on:

- **JSF (JavaServer Faces)** — The view framework providing backing bean lifecycle, EL evaluation, and navigation.
- **JSP** — The view rendering technology. Pages use JSP with EL expressions to bind to bean properties.
- **XML configuration** — Multiple XML files manage managed-bean registration, action mappings, and external wiring.

### Outbound

No internal package dependencies were detected. Classes import only from the Java standard library, keeping the module lightweight and decoupled from application-specific services.

## Notes for Developers

- **Extend logic, not beans** — When adding functionality to a view, start in the logic class's `execute()` method. Beans should remain lean, exposing only the state the view needs to render.

- **Read-only by design** — If a bean has no setter, user input cannot be two-way-bound. Adding a `setValue()` method following standard JSF conventions is required if two-way binding is needed.

- **Check all XML config files** — Configuration for a view may be spread across `faces-config.xml`, `WEBGAMEN_*.xml`, `x33S_*.xml`, and `external-refs.xml`. Changes to managed-bean settings should be reviewed in all four files to avoid conflicts or overwrites.

- **Navigation limitation** — `execute()` returns `void`, so it cannot produce a JSF navigation outcome string. Navigation must instead be handled by modifying bean state that JSF reads, or by calling `ExternalContext.redirect()` from within the logic method.

- **Two source trees** — When modifying a logic class, update the canonical version in `full-fixture-codebase`. The `xml-unresolved-fqn` variant is a derived copy and may lack Javadoc that exists in the primary source.

- **Naming convention** — Sub-module names follow an `ACA + N + SF` pattern (e.g., `ACA001SF`). The prefix and numeric suffix likely correspond to internal feature or requirement identifiers. The domain label ("Futurity" in the Javadoc) provides additional context about the business area the view serves.