# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a JavaServer Faces (JSF)–based web module responsible for rendering server-side views within the application. It follows a classic MVC pattern where backing beans provide the data model, JSP/JSF pages render the UI, and action classes mediate user interactions. The module is wired through a mix of JSF (`faces-config.xml`) and additional XML configuration files, suggesting a layered or multi-profile view stack (possibly integrating with other MVC frameworks such as Struts for certain view profiles).

At the top level, `webview` contains named sub-modules (each with a code-like identifier such as `ACA001SF`), where each sub-module corresponds to a distinct view or feature area. This appears to be a modular-by-namespace approach: each view gets its own package under `eo.web.webview`, keeping beans, logic, configs, and JSPs co-located.

## Sub-module Guide

### ACA001SF — Futurity View

`ACA001SF` is the primary (and currently only indexed) sub-module in this package. It powers the "Futurity" page — a single JSF view backed by a minimal data model.

**What it does:** `ACA001SF` consists of two core classes:

- **`ACA001SFBean`** — the JSF managed backing bean, exposing a single read-only `String` property (`value`) that JSP EL expressions (e.g., `#{aca001sfBean.value}`) bind to for rendering.
- **`ACA001SFLogic`** — the action/controller class. Its `execute()` method is the entry point for form submissions or command-link triggers on the view. Currently, it is a no-op placeholder.

This module is a **structural scaffold / stub** — the implementation is intentionally minimal, likely intended to be expanded as the Futurity feature evolves.

**How it relates to the rest of the system:** Although the logic class is empty, the sub-module is referenced by **5 XML configuration files** and at least **2 JSP views**, meaning it is integrated into a broader view hierarchy. The multiple registration paths (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `external-refs.xml`) suggest this view is served under different scopes, configurations, or action-mapping profiles across the application.

## Key Patterns and Architecture

### JSF MVC Pattern

Each sub-module under `eo.web.webview` follows a consistent three-part structure:

1. A **backing bean** (JSF managed bean) that exposes properties via getters/setters.
2. A **logic/action class** that handles server-side actions (form submissions, navigation).
3. **JSP/JSF view pages** that bind to the bean via EL expressions.

This pattern keeps presentation, data, and action logic cleanly separated within each sub-module's namespace.

### Request Flow

The typical request lifecycle through this module looks like this:

```
flowchart TD
    A["Request Flow"] --> B["User navigates to Futurity page"]
    B --> C["JSF resolves ACA001SFBean"]
    C --> D["JSP renders view via EL expressions"]
    D --> E["Action dispatched to ACA001SFLogic.execute()"]
    E --> F["Currently no-op, no state changes"]

    subgraph Core["Core Components"]
        G["ACA001SFBean
JSF backing bean"]
        H["ACA001SFLogic
Action/controller class"]
    end

    subgraph Config["Configuration"]
        I["faces-config.xml"]
        J["WEBGAMEN_FULL_ACA001.xml"]
        K["WEBGAMEN_ACA001010PJP.xml"]
        L["x33S_ACA001.xml"]
        M["external-refs.xml"]
    end

    subgraph Views["JSP Views"]
        N["FULL_ACA001010PJP.jsp"]
        O["Other JSP pages"]
    end

    I --> G
    J --> G
    J --> H
    K --> G
    K --> H
    L --> G
    L --> H
    M --> H
    N --> G
    N --> H
    O --> G
    O --> H
    G --> H
```

### Multiple Registration Paths

The same bean and logic classes are registered across multiple XML configuration files. This appears intentional, allowing the same view components to operate under different scopes or initialization parameters depending on which config profile is active. Developers should inspect each XML file to understand the lifecycle context (request, view, session, application scope) in which a given bean operates.

### Dual Source Variants

Some classes (notably `ACA001SFLogic`) exist in dual source paths — a full-fixture source and an XML-unresolved-FQN source. Both have identical empty implementations but differ in Javadoc presence. This suggests a multi-branch or multi-profile build strategy. Changes to shared logic should be applied consistently across both paths to avoid divergence.

## Dependencies and Integration

### Inbound (who calls into this module)

- **XML configurations** — `faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, and `external-refs.xml` all reference the beans and logic classes, registering them as managed beans or actions.
- **JSP view pages** — At least `FULL_ACA001010PJP.jsp` binds directly to the backing bean and logic class via EL expressions.

### Outbound (what this module depends on)

No outbound dependencies to other modules were detected in the index. The stub implementations do not currently import or reference any external services, repositories, or application components. Any new services required by expanding sub-modules should be wired through dependency injection or XML configuration.

## Notes for Developers

- **Stub-level implementations.** Both `ACA001SFBean` and `ACA001SFLogic` are scaffolds. The `execute()` method in `ACA001SFLogic` is the primary extension point — this is where business logic should be added when the Futurity feature grows.
- **Read-only bean properties.** The backing bean exposes a getter but no setter for its `value` field. If the view needs to accept user input, a setter should be added, or the field should be populated via `@PostConstruct` initialization or DI injection.
- **Multiple configs, multiple lifecycles.** The same classes are registered in several XML files. Verify each config's scope and initialization parameters — behavior may differ depending on which config profile is active for a given request.
- **Keep sub-modules self-contained.** The convention of one sub-package per view (e.g., `eo.web.webview.ACA001SF`) helps keep beans, logic, configs, and JSPs co-located. Follow this pattern when adding new views.
- **Watch dual source paths.** If you modify `ACA001SFLogic`, check whether a corresponding file exists in the `xml-unresolved-fqn` source path and keep both in sync unless a clear canonical source has been designated.