# Eo / Web

## Overview

The `eo.web` package serves as the web presentation layer for the Eo application. It is a Java EE / JSF-based module that renders user-facing pages, organizing screen-specific sub-packages under a `webview` sub-package. Each screen (identified by a screen code such as `ACA001SF`) owns its full request/response lifecycle — backing bean, action logic, and JSP view — without importing Java packages from other modules. The module's responsibility is primarily organizing and wiring these screens together through XML-based configuration (`faces-config.xml`, module-specific XML files) rather than through code-level dependencies.

This module does not contain Java source files at its own top level; instead, it delegates all functionality to its `webview` child package, which in turn contains screen-level sub-packages. This makes `eo.web` a structural parent that defines the package hierarchy and shared wiring conventions for the presentation layer.

## Sub-module Guide

### `webview` — Screen Renderers

The `webview` sub-package holds all the actual presentation code. It is organized by screen codes, where each sub-package (e.g., `ACA001SF`) implements a single page with three components:

- **Bean** — A JSF backing bean that carries page-scoped data (e.g., `ACA001SFBean` with a `value` field).
- **Logic** — An action handler class with an `execute()` method that JSF calls on form submission (e.g., `ACA001SFLogic`).
- **Views and Config** — JSP files for rendering and XML files for bean registration, navigation, and external references.

Currently, only `ACA001SF` (the "Futurity" page) is indexed. New screens would follow the same pattern: a new sub-package with its own bean, logic, JSP, and XML configs.

The relationship between `webview` and its screen sub-packages is flat — each screen is independent. Screens communicate only through JSF navigation outcomes (string-based result codes) and shared XML configuration, not through direct Java-level calls. This keeps each screen self-contained and independently deployable.

## How It Works

The request flow for any screen in the `webview` package 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
```

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 a JSP view (e.g., `FULL_ACA001010PJP.jsp`). The JSP references the bean and 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, placing it into the appropriate scope.
3. **Rendering** — The JSP reads bean properties via EL to display content or bind form inputs.
4. **Action handling** — On form submission, JSF invokes the logic class's `execute()` method.
5. **Redisplay** — JSF re-renders the page with updated bean state.

## Key Patterns and Architecture

### JSF MVC with XML Wiring

The entire `webview` 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, and any change to bean scope or properties requires corresponding XML updates.

### Screen-Scoped Encapsulation

Each screen sub-package is self-contained: it owns its bean, logic class, JSP views, and configuration files. There are no inter-screen Java imports — screens communicate solely through JSF navigation outcomes and shared configuration. This isolation makes each screen independently deployable and relatively independent from others.

### Minimal Data Model

The bean pattern uses plain Java objects with JavaBeans-style getters and setters. `ACA001SFBean` has a single field as an example, but the pattern scales: additional fields are added as `private` fields with corresponding getters following the JavaBeans convention.

## Dependencies and Integration

### XML Configuration Ecosystem

The module depends entirely on XML-based wiring rather than Java-level dependencies:

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

### Isolation from Other Modules

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

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

This architectural isolation means the module can be modified or replaced without affecting unrelated parts of the application, though it also means cross-screen communication must flow 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 both its directory and package name. New screens should follow the same naming convention.
- **Empty action handlers** — The `execute()` method in logic classes is the entry point for business logic. It may currently be empty, suggesting logic is delegated to external services, driven by configuration, or awaiting implementation.
- **Dual source trees** — Some logic classes 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. Beans are not auto-discoverable and must be registered explicitly.
- **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`).
- **No Java-level cross-module deps** — If you need to call logic in another module, do so through the configuration layer or a shared service, not through a direct Java import. This preserves the module's isolation.