# Eo / Web

## Overview

The `eo.web` package is the web presentation layer of the EO application. It provides the user-facing surface of the system, rendering data to users through JavaServer Faces (JSF) backed views. Rather than owning business logic itself, this package acts as the bridge between the application's business / service layer and the end user — accepting user requests, delegating to logic handlers that fetch or compute data, and rendering the results via JSP views.

The package targets an older JSF lifecycle model (1.x or early 2.x), relying on XML-based bean registration in `faces-config.xml` rather than annotation-driven configuration. This means new components added here must follow the traditional XML wiring pattern unless the application's JSF version has since been upgraded.

At the time of this documentation, the package contains a single sub-module area: the `webview` package, which handles a futurity (forward-looking) view use case.

## Sub-module Guide

### webview — JSF MVC Presentation Scaffold

The `webview` sub-package is currently a lightweight JSF MVC scaffold centered on one view module: `ACA001SF`.

`ACA001SF` follows the classic two-class JSF pattern:

- **`ACA001SFBean`** — A JSF backing bean holding a single `String value` property. With only a getter (no setter), the value is populated programmatically by the logic class rather than bound to user input.
- **`ACA001SFLogic`** — A logic handler whose `execute()` method is the entry point for the view. The method body is currently empty, marking this as a stub awaiting business logic implementation. The Javadoc labels it as "Futurity view logic," indicating it is intended to display forward-looking or anticipated-state data once fully developed.

This sub-module is already wired into the broader application through multiple configuration files (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`) and at least one JSP view (`FULL_ACA001010PJP.jsp`), even though its own implementation remains minimal.

The two-class relationship inside `ACA001SF` is straightforward:

```
ACA001SFLogic  -->  prepares data  -->  ACA001SFBean  -->  renders via EL  -->  JSP view
```

There are no nested objects, collections, or cross-module data dependencies within this sub-module at this level. Any future business logic will need to be added into `ACA001SFLogic.execute()` and written to the bean for rendering.

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. These should be treated as different fixture configurations rather than divergent implementations.

## Key Patterns and Architecture

### JSF MVC Pattern

The entire `eo.web` package follows a uniform two-class MVC pattern:

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

The backing bean is the model object visible to the view. The logic handler serves as the controller, fetching or computing data and writing it to the bean. The JSP (or Facelet) view renders the bean's properties via JSF Expression Language (EL).

### Configuration-Driven Wiring

Bean registration and view wiring are managed entirely through external XML descriptors (`faces-config.xml` and supplemental `WEBGAMEN_*`, `x33S_*` files). This keeps the bean classes as lightweight POJOs without annotation-heavy configuration, 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 structural scaffolding is laid out and wired into the JSF lifecycle first, with the expectation that business logic will be integrated later. This pattern means that any developer extending this module should treat the existing classes as scaffolding rather than production-ready logic.

### Data Flow

The current data model is intentionally simple — a single `String` field flowing from the logic class into the bean and then into the view. Future extensions will need to introduce more complex data structures into `ACA001SFLogic.execute()`, at which point the backing bean and view bindings will also need to evolve to support them.

## Module Interaction Diagram

The following diagram shows how the `webview` sub-module sits within the `eo.web` package and interacts with configuration, views, and its internal components:

```mermaid
flowchart TD
    subgraph eo_web["eo.web Package"]
        Webview["eo.web.webview
JSF presentation layer"]
    end

    subgraph Webview_Internal["Webview Internal Structure"]
        Bean["ACA001SFBean
backing bean"]
        Logic["ACA001SFLogic
view logic handler"]
        Views["JSP views
FULL_ACA001010PJP.jsp"]
    end

    Logic -->|"prepares data"| Bean
    Bean -->|"renders via EL"| Views
    Logic -->|"managed by"| Configs["XML configs
faces-config.xml, WEBGAMEN_*.xml"]
```

## Dependencies and Integration

### Incoming Dependencies

The `webview` module is consumed by several configuration and view files that define its place in 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

This 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 to prepare data for the view.

### Extension Points

When implementing the futurity logic, the intended extension point is `ACA001SFLogic.execute()`. This is where business service calls or data-access logic should be added, with results written to the bean's `value` field for rendering in the JSP view. If the data model needs to grow beyond a single `String`, both the bean (adding a setter and additional properties) and the view bindings will need to be updated accordingly.

## 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.