# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a JavaServer Faces (JSF)–based web presentation layer within the EO application. It follows the standard JSF MVC pattern, where managed backing beans hold view-scoped data and companion `*Logic` classes handle the request processing that populates that data before the JSP view renders. The webview package is the bridge between business logic and the user interface, wired into the JSF lifecycle through `faces-config.xml` and referenced by XML configuration descriptors and JSP pages scattered across the application.

This area of the codebase appears to serve a "futurity view" use case — the logic class's Javadoc explicitly labels itself as such — and its current implementation is minimal, suggesting it is either an early scaffold or a stub awaiting further business logic to be integrated.

## Sub-module Guide

The webview package currently contains one documented child sub-module:

### ACA001SF — Futurity View Logic

`ACA001SF` is the smallest possible JSF MVC unit. It consists of two classes working together:

- **`ACA001SFBean`** — A standard JavaBeans POJO holding a single `String value` field. The presence of only a getter (no setter) suggests the value is populated programmatically by the logic class or injected by the JSF container, rather than bound directly to user input fields. JSF expression language (`#{aca001sFBean.value}`) binds this property to the JSP view.

- **`ACA001SFLogic`** — The view logic handler whose `execute()` method serves as the entry point when a user action triggers a page request. The method body is currently empty, marking this as a stub or placeholder. The Javadoc comment "Futurity view logic" indicates this module is intended to display forward-looking or anticipated-state data once implemented.

These two classes follow the classic JSF request flow:

1. A user navigates to a JSP view (e.g., `FULL_ACA001010PJP.jsp`).
2. JSF instantiates the `ACA001SFBean` managed bean.
3. The `ACA001SFLogic.execute()` method is invoked to prepare data.
4. The logic class sets values on the bean.
5. The JSP renders using EL expressions bound to the bean's properties.

The sub-module is referenced by four XML configuration files (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`) and at least one JSP view, indicating it is integrated into the broader application configuration even though its own implementation is lightweight.

Note that `ACA001SFLogic` exists in two codebase variants (`full-fixture-codebase` and `xml-unresolved-fqn`), likely representing different build configurations or fixture sets. The full-fixture version carries the Javadoc comment; the other does not.

## Key Patterns and Architecture

### JSF MVC Pattern

Every sub-module in this package follows the same two-class pattern:

```
[Backing Bean] <--> [Logic Handler]
       ^                    |
       |                    | prepares data
       |                    v
       +---- JSP View <----+
```

The backing bean is the model object visible to the view. The logic handler is the controller that fetches or computes data and writes it to the bean. The JSP (or Facelet) view renders the bean's properties via JSF EL.

### Configuration-Driven Wiring

Bean registration is managed externally via `faces-config.xml` and supplemental XML descriptors (`WEBGAMEN_*`, `x33S_*`). This keeps the bean classes lightweight POJOs without annotation-heavy configuration, which is consistent with a traditional JSF 1.x / early JSF 2.x deployment model.

### Stub-First Development

The empty `execute()` body and the absence of a setter on the bean's value field suggest a stub-first development approach: the structure is laid out, wired into the lifecycle, and then business logic is expected to be filled in later. Any developer extending this module should treat the existing classes as scaffolding rather than production-ready logic.

### Data Flow

The data model is intentionally simple — a single `String` field flowing from the logic class into the bean and then into the view. There are no nested objects, collections, or cross-module data dependencies at this level. Any complex data will need to be introduced into `ACA001SFLogic.execute()` when the futurity logic is fully implemented.

## Dependencies and Integration

### Incoming Dependencies

This module is consumed by configuration and view files that define how it fits into the application:

| Consumer | Uses |
|----------|------|
| `faces-config.xml` | `ACA001SFBean` (managed bean registration) |
| `WEBGAMEN_FULL_ACA001.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `WEBGAMEN_ACA001010PJP.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `x33S_ACA001.xml` | `ACA001SFBean`, `ACA001SFLogic` |
| `FULL_ACA001010PJP.jsp` | `ACA001SFBean`, `ACA001SFLogic` |
| `external-refs.xml` | `ACA001SFLogic` |

### Framework Dependencies

The module depends on the JSF runtime and standard JavaBeans conventions. It does not import any external application packages, meaning it is a pure presentation-layer component. Business logic integration would occur inside `ACA001SFLogic.execute()`, where service-layer calls or data-access queries would be added.

### Module Interaction Diagram

```mermaid
flowchart TD
    subgraph Webview["eo.web.webview Package"]
        ACA001SF["ACA001SF
(view logic module)"]
    end

    subgraph ACA001SF_Module["ACA001SF Sub-module"]
        Bean["ACA001SFBean
(JSF backing bean)"]
        Logic["ACA001SFLogic
(view logic handler)"]
    end

    Bean -.->|"data binding"| Views["JSP views
(FULL_ACA001010PJP.jsp)"]
    Logic -.->|"managed by"| Configs["XML configs
(faces-config, WEBGAMEN_*.xml, x33S_ACA001.xml)"]
    Bean -.->|"data from"| Logic
```

## Notes for Developers

- **Stub implementation:** The current logic class has an empty `execute()` method. If you are working in the `full-fixture-codebase`, check sibling modules or parent services for actual business logic that may need to be wired into this view layer.
- **Two codebase variants:** `ACA001SFLogic` exists in both `full-fixture-codebase` and `xml-unresolved-fqn` paths. The full-fixture version includes a Javadoc comment ("Futurity view logic") absent from the other. Treat these as different fixture configurations rather than divergent implementations.
- **Bean naming:** The class `ACA001SFBean` follows the JSF convention of suffixing managed beans with `Bean`. The default EL name would be the uncapitalized form (e.g., `aca001sFBean`). Verify the exact name by checking `faces-config.xml`, as XML declarations can override the default.
- **No setter on value:** The bean exposes only a getter. If user-facing input binding is needed in the future, a setter (`setValue(String)`) must be added.
- **Extension point:** When implementing the futurity logic, `ACA001SFLogic.execute()` is the intended extension point. Add business service calls or data-access logic here, and write results to the bean's `value` field for rendering in the JSP view.
- **JSF version context:** The reliance on `faces-config.xml` for bean registration (rather than `@ManagedBean` or `@Named` annotations) suggests this codebase targets an older JSF version (1.x or early 2.x). When adding new components, consider whether annotation-based configuration is available or if XML wiring is still required.