# Eo / Web / Webview

## Overview

`eo.web.webview` is a JavaServer Faces (JSF) web sub-package that implements server-side backing beans and action logic for individual JSF page views. It follows a two-class-per-view convention: a **backing bean** that carries view-scoped state as JavaBeans properties, and a **logic class** that provides the `execute()` method invoked when a user action (form submission, command button click) occurs.

This area of the codebase represents the JSF view tier — the bridge between JSP pages and server-side business processing. Each leaf package under `eo.web.webview` (named by a code such as `ACA001SF`) corresponds to a single JSF page and encapsulates all view-specific state and action handlers for that page.

The current code index indicates the module exists at the `subpackage` level but contains no indexed source files in the current snapshot. The only documented child module is `ACA001SF`, which serves as a representative example of the pattern used throughout the package.

## Sub-module Guide

### ACA001SF — Minimal JSF view scaffold

`ACA001SF` is a leaf module representing a single JSF view: `FULL_ACA001010PJP.jsp`. It contains exactly two classes:

- **ACA001SFBean** — The backing bean. It exposes a single read-only `String value` property via `getValue()`. In the JSF lifecycle, this bean is resolved from `faces-config.xml` and its properties are bound to UI components in the JSP using EL expressions (e.g., `#{aca001sfBean.value}`).

- **ACA001SFLogic** — The action-behavior class. It provides an `execute()` method that is invoked by the JSF page as an action handler. Currently this method is a no-op stub; the class-level Javadoc comment ("Futurity view logic") indicates it was scaffolded for a future feature that has not yet been implemented.

`ACA001SF` is wired into **four XML configuration files** (`WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `faces-config.xml`) plus an external reference file (`external-refs.xml`), suggesting it participates in multiple navigation contexts across the application.

> **Relationship insight:** `ACA001SF` illustrates the full pattern for any view under `eo.web.webview`. If additional child modules exist beyond this indexed sample, they will follow the same bean/logic split. The multiple XML wiring contexts suggest the pattern supports a modular navigation architecture where the same view component can be plugged into different workflow scenarios without code changes — the wiring is declarative in XML rather than hard-coded in Java.

## Key Patterns and Architecture

### Two-class JSF view pattern

Every view module in `eo.web.webview` follows a consistent two-class split:

```
[JSF page JSP]  <-->  [Bean: state holder]  <-->  [Logic: action handler]
```

This separation of concerns maps directly to the JSF model:
- **Bean** — holds data that survives across the page lifecycle (render model, render response, invoke application phases). Properties are exposed via getters/setters and bound to UI components via EL.
- **Logic** — contains side-effectful methods (typically `execute()`) that are called as action handlers. By convention, the return type and name determine the JSF navigation outcome.

### Stub / scaffold pattern

The `ACA001SF` module's `execute()` method is an empty no-op, and the bean has only a single trivial property. This suggests the package contains many such scaffolds — modules created as structural placeholders where business logic will be implemented later. The "Futurity view logic" Javadoc is a deliberate indicator of this intent.

### XML-driven wiring

Rather than using annotation-based discovery, the module relies on XML configuration (`faces-config.xml` for managed beans, `WEBGAMEN_*.xml` and `x33S_*.xml` for navigation rules). This approach allows the same bean and logic classes to be reused across different navigation flows by simply adding or modifying XML entries — no Java code changes required.

### Request flow

The typical request lifecycle through any module in `eo.web.webview`:

1. **JSF Page Render Phase** — JSF resolves the bean from `faces-config.xml`, instantiates it, and binds its properties to UI components in the JSP via EL.
2. **User Action** — The user submits the form or clicks a command button/link.
3. **Invoke Application Phase** — JSF calls the logic class's `execute()` method as specified in the component's `action` attribute.
4. **JSF Render Response Phase** — The return value of `execute()` (or `void`) determines the navigation outcome.

```
Browser (JSP page)
  |
  |-- JSF Page Render --> Bean.getValue() (populates UI)
  |
  |-- JSF Invoke Application --> Logic.execute() (action handler)
  |
  |-- JSF Render Response --> Browser (redirect or forward)
```

## Dependencies and Integration

### Inbound dependencies (consumers of this module)

The `ACA001SF` module is referenced by the following files:

| File | Classes Referenced |
|------|-------------------|
| `faces-config.xml` | `ACA001SFBean` |
| `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` |

These represent:
- **Managed-bean registration** — `faces-config.xml` declares the bean and its scope.
- **View navigation rules** — `WEBGAMEN_*.xml` and `x33S_ACA001.xml` define which pages navigate to/from this view and what outcomes each action produces.
- **External wiring** — `external-refs.xml` suggests this module is referenced from outside the standard JSF flow (possibly by a routing or dispatch mechanism).

### External dependencies

This module depends on:
- **JavaServer Faces (JSF)** — the backing bean and logic classes are standard JSF artifacts.
- **JSP** — the view layer is implemented as a `.jsp` file with JSF tag libraries.
- **XML configuration** — `faces-config.xml` and navigation rule files are declarative dependencies.

## Notes for Developers

- **Stub code is the norm.** The `ACA001SF` module is a no-op scaffold. If you encounter similar classes with empty `execute()` methods throughout the package, this is expected — the module was created as a structural placeholder. Look for "futurity" or "future" Javadoc comments as indicators of intended-but-not-yet-implemented features.

- **Read-only bean properties.** `ACA001SFBean` exposes `value` only via a getter. If you create a new bean and need form input binding (e.g., `<h:inputText value="#{bean.property}"/>`), remember to provide a corresponding setter.

- **Entry point for new logic.** When extending a view module, the primary integration point is the `execute()` method on the logic class. This is where business processing, validation, and navigation decisions belong.

- **XML wiring is the extension mechanism.** To add this view to a new workflow, you do not modify Java code — you add entries to the appropriate `WEBGAMEN_*.xml` or `x33S_*.xml` navigation files and ensure the bean is registered in `faces-config.xml`.

- **No child sub-packages.** `eo.web.webview` is a flat hierarchy — there are no nested packages beyond the leaf view modules like `ACA001SF`. Each code (e.g., `ACA001SF`) is its own leaf package.

## Architecture diagram

The following diagram shows how the `ACA001SF` module connects to the broader webview architecture:

```mermaid
flowchart TD
    subgraph webview["eo.web.webview"]
        direction TB
        ACA001SF["ACA001SF"]
    end

    subgraph ACA001SF_group["ACA001SF - JSF View Component"]
        direction TB
        A["ACA001SFBean<br/>Backing bean<br/>String value property"]
        B["ACA001SFLogic<br/>Action logic<br/>Stub execute()"]
        C["FULL_ACA001010PJP.jsp<br/>JSF page"]
    end

    ACA001SF --> ACA001SF_group
    A --> C
    B --> C
    A -.->|JSF EL binding| C
    B -.->|action=| C

    subgraph config["XML Wiring"]
        D["faces-config.xml<br/>Managed bean registration"]
        E["WEBGAMEN_FULL_ACA001.xml<br/>Navigation rules"]
        F["WEBGAMEN_ACA001010PJP.xml<br/>Navigation rules"]
        G["x33S_ACA001.xml<br/>Navigation rules"]
        H["external-refs.xml<br/>External wiring"]
    end

    D -.-> A
    E -.-> A
    E -.-> B
    F -.-> A
    F -.-> B
    G -.-> A
    G -.-> B
    H -.-> B
```