# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a Java EE / JSF-based web presentation layer that renders user-facing pages. Each sub-package under this module corresponds to a specific screen or functional area (identified by codes like `ACA001SF`) and follows a standard JSF MVC pattern: a backing bean holds page-scoped data, a logic class acts as the action handler, and JSP view files compose the rendered HTML.

This module does not contain its own Java source files at the top level — its responsibility is organizing screen-specific sub-packages. Each sub-package (e.g., `ACA001SF`) encapsulates the full request/response lifecycle for a single page: bean binding, view rendering, and action handling. Integration with the rest of the application is primarily through XML-based configuration (`faces-config.xml`, module-specific XML files) rather than Java-level cross-module imports.

## Sub-module Guide

### ACA001SF — Futurity Page

**ACA001SF** is a sub-package that renders the "Futurity" page. It is the primary (and currently indexed) child of the `webview` package and consists of three core components:

- **ACA001SFBean** — A lightweight JSF backing bean that carries a single `String value` field. It bridges the JSP view and the action logic layer, exposing `value` via a standard getter so the JSP can bind form inputs or display data through EL (`#{aca001sfBean.value}`).
- **ACA001SFLogic** — An action handler class with an `execute()` method that JSF invokes on form submission. The current implementation body is empty, suggesting the business logic is either delegated to external services, driven by configuration, or awaiting implementation.
- **View and Config Files** — A JSP (`FULL_ACA001010PJP.jsp`) references both the bean and logic class directly, while five XML configuration files (`WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `faces-config.xml`, `external-refs.xml`) wire up bean scoping, navigation rules, and external references.

The naming convention (`ACA001SF`) suggests a screen/function code pattern. New pages in this module would follow the same structure under their own sub-package (e.g., `ACA002SF`, `ACA003SF`), each with their own bean, logic, and view.

## How It Works

The request flow for any screen in this module follows the standard JSF lifecycle:

```mermaid
sequenceDiagram
    participant User
    participant JSP as JSP_VIEW
    participant BEAN as ACA001SFBean
    participant LOGIC as ACA001SFLogic

    User->>JSP: Navigates to page
    JSP->>BEAN: Reads bean property via EL
    JSP-->>User: Renders page with data

    User->>JSP: Submits form or clicks action
    JSP->>LOGIC: Calls execute()
    LOGIC-->>JSP: Returns control

    JSP->>BEAN: Updates with new state
    JSP-->>User: Re-renders updated page
```

### Static Wiring

The components are connected through XML configuration rather than annotations or Java-level imports:

```mermaid
flowchart LR
    JSP["FULL_ACA001010PJP.jsp"] --> BEAN["ACA001SFBean"]
    JSP --> LOGIC["ACA001SFLogic"]
    BEAN --> XML1["WEBGAMEN_FULL_ACA001.xml"]
    BEAN --> XML2["WEBGAMEN_ACA001010PJP.xml"]
    BEAN --> XML3["x33S_ACA001.xml"]
    BEAN --> XML4["faces-config.xml"]
    LOGIC --> XML1
    LOGIC --> XML2
    LOGIC --> XML3
    LOGIC --> XML5["external-refs.xml"]
```

1. **Navigation** — A user navigates to the page (e.g., `FULL_ACA001010PJP.jsp`). The JSP references both the bean and the logic class directly in its view code.
2. **Bean binding** — JSF resolves the bean via XML configuration entries in `faces-config.xml` and module-specific configs. The bean is placed into an appropriate scope (request, session, or view).
3. **Rendering** — The JSP reads the bean property via EL to display content or bind form inputs.
4. **Action handling** — When the user submits the page, JSF invokes the logic class's `execute()` method.
5. **Redisplay** — JSF re-renders the page with the updated bean state.

## Key Patterns and Architecture

### JSF MVC with XML Wiring

The entire module follows a traditional JSF 1.x-style MVC pattern where navigation, bean lifecycle, and action binding are controlled through XML configuration files (`faces-config.xml`, `WEBGAMEN_*`, `x33S_*`) rather than annotation-based discovery. This means:

- Every bean must be explicitly registered in XML to be available to the JSF runtime.
- Changing the bean's scope or adding new properties requires corresponding XML updates.
- Navigation outcomes and security constraints are defined in the same XML ecosystem.

### Screen-Scoped Encapsulation

Each sub-package (e.g., `ACA001SF`) is self-contained: it owns its bean, its logic class, its JSP views, and its configuration. There are no inter-screen Java imports — screens communicate through JSF navigation outcomes and shared configuration files. This makes each screen independently deployable and relatively isolated from others in the same package.

### Minimal Data Model

The bean pattern keeps the data model simple — a POJO with JavaBeans-style getters and setters. The `ACA001SFBean` has a single field, but this pattern scales: additional fields are added as `private` fields with corresponding getters (and optionally setters) following the JavaBeans convention.

## Dependencies and Integration

### XML Configuration Ecosystem

The module depends entirely on XML-based wiring:

| Config File | Purpose |
|---|---|
| `faces-config.xml` | Registers beans with JSF, defines scopes |
| `WEBGAMEN_*` files | Page navigation rules, module-specific config |
| `x33S_*` files | Additional module configuration |
| `external-refs.xml` | Exposes logic classes to other modules or external callers |

### No Java-Level Cross-Module Dependencies

This module does not import Java packages from other modules. Integration with the rest of the application is entirely through:

- XML configuration references
- JSP view composition (including tags and includes)
- JSF navigation outcomes (string-based result codes)

This isolation means the module can be modified or replaced without affecting unrelated parts of the application, but it also means cross-screen communication must go through the shared XML configuration and JSF lifecycle.

## Notes for Developers

- **Screen code pattern** — Each sub-package uses a screen code (e.g., `ACA001SF`) as its directory and package name. New screens follow the same naming convention.
- **Empty action handler** — The `execute()` method in logic classes is the entry point for business logic. If you are extending a page, this is where implementation goes.
- **Dual source trees** — Some logic classes (like `ACA001SFLogic`) exist in multiple source trees (`full-fixture-codebase` and `xml-unresolved-fqn`). Be aware of which tree you are modifying, as they may diverge.
- **XML-heavy wiring** — Adding or modifying beans and logic classes requires updates to the relevant XML config files. The bean is not automatically discoverable without XML registration.
- **Bean scope matters** — The bean's scope is determined by `faces-config.xml`. If a bean needs to persist across multiple requests, the scope must be changed there (e.g., from `request` to `session`).