# Eo

## Overview

The `eo` module is the top-level web presentation layer for the application. Built on Java EE and JSF 1.x, it renders user-facing pages and organizes them as a collection of self-contained screens. Each screen owns its full request/response lifecycle — a backing bean, action logic, and JSP view — with no Java-level imports across screens or into other modules. Instead, screens are wired together through XML configuration (`faces-config.xml` and module-specific XML files), making the module a structural parent that defines conventions for the entire presentation tier.

The `eo` module does not contain Java source files at its own top level. All functionality is delegated to the `web` sub-package, which in turn delegates to `webview` — a collection of screen-level sub-packages organized by screen code (e.g., `ACA001SF`). This makes `eo` a hierarchy of package structure and XML-based wiring, where the actual behavior lives entirely in the screen renderers below.

## Package Structure

```mermaid
flowchart TD
    EO["Eo Package<br/>eo"]
    WEB["Web Layer<br/>eo.web"]
    WEBVIEW["Web Views<br/>eo.web.webview"]
    SCREENS["Screen Sub-packages<br/>e.g. ACA001SF, ACA002SF ..."]

    EO --> WEB
    WEB --> WEBVIEW
    WEBVIEW --> SCREENS

    BEAN["Backing Bean<br/>per screen"]
    LOGIC["Action Logic<br/>per screen"]
    JSP["JSP View<br/>per screen"]
    XMLCFG["XML Configuration<br/>faces-config, WEBGAMEN, x33S, external-refs"]

    SCREENS --> BEAN
    SCREENS --> LOGIC
    SCREENS --> JSP
    BEAN --> XMLCFG
    LOGIC --> XMLCFG
```

The hierarchy is strictly layered: `eo` contains `eo.web`, which contains `eo.web.webview`, which contains individual screen packages. At the screen level, each package self-contained with its bean, logic class, JSP views, and XML configuration files.

## Sub-module Guide

### `web` — Presentation Entry Point

The `eo.web` package is the structural parent for the presentation layer. It does not contain Java source files at its own top level; instead, it defines the package hierarchy and shared wiring conventions for everything below it. All presentation logic flows through its `webview` sub-package, making `web` a lightweight organizing container.

### `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. Each screen sub-package contains three core components:

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

Screens are arranged in a flat hierarchy under `webview` — each screen is independent and communicates only through JSF navigation outcomes (string-based result codes) and shared XML configuration, not through direct Java-level calls. This isolation makes each screen independently deployable.

### Relationship Between Sub-modules

The `web` package serves as the namespace root for all presentation code. It delegates all actual behavior to `webview`, which organizes code by screen. Adding a new screen means adding a new sub-package under `webview` with the standard three-component pattern (bean, logic, JSP + XML). The module's responsibility is primarily organizing and wiring these screens together through XML rather than through code-level dependencies.

## How It Works

### Request Flow

The request flow for any screen in the `webview` package follows the standard JSF lifecycle:

```mermaid
sequenceDiagram
    participant User
    participant JSP as JSPView
    participant BEAN as BackingBean
    participant LOGIC as LogicHandler

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

### Wiring Diagram

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

```mermaid
flowchart LR
    JSP["JSP View"] --> BEAN["Backing Bean"]
    JSP --> LOGIC["Action Logic"]
    BEAN --> XMLCFG["XML Configuration"]
    LOGIC --> XMLCFG
```

1. **Navigation** — A user navigates to a JSP view. The JSP references the bean and logic class 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. Beans follow a simple convention: fields are declared as `private`, and corresponding getter methods follow the standard JavaBeans naming pattern. This keeps the data model trivially simple and focused on view concerns rather than domain logic.

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

The `eo` 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.