# Eo

## Overview

The `eo` package serves as the top-level entry point for the application's **presentation layer**. Everything in this area is concerned with how users interact with the system — rendering views, dispatching user actions, and routing navigation. It is not a domain or business-logic layer; rather, it is the thin tier that sits between the user's browser and the rest of the application stack, translating UI events into requests that downstream services can process.

At a high level, `eo` delegates all web-facing concerns to its child module, `eo.web`, which is built on **JavaServer Faces (JSF)**. The entire package follows a uniform convention: every feature page is structured identically with a managed bean for view state and a logic class for action handling, all wired together through XML configuration files.

## Sub-module Guide

`eo` contains a single child module:

- **[`eo.web`](eo/web.md)** — The core web presentation module. This sub-package contains all JSF-managed views, beans, and logic classes. It is organized around the **`webview`** sub-package, where each feature (such as the "Futurity" page, `ACA001SF`) is independently implemented.

### How the sub-modules relate

`eo.web` is the only child of `eo`, and `eo` itself is essentially an alias for the web presentation tier — there are no other layers (e.g., services, data access) nested under `eo`. Within `eo.web`, all feature packages under `webview` are **parallel and self-contained**: they share a common architectural pattern (Bean + Logic classes) but do not import from or depend on sibling packages. The module as a whole is a collection of independent feature pages bound together by convention and XML wiring, not by shared code.

```mermaid
flowchart TD
    user["User / Browser"] --> view["JSP/JSF Views"]
    view --> bean["Managed Bean
(e.g., ACA001SFBean)"]
    view --> logic["Logic Class
(e.g., ACA001SFLogic)"]
    bean --> config["faces-config.xml"]
    logic --> config
    config --> outcome["Navigation Outcome
(next JSP page)"]
    outcome --> view
```

The diagram above captures the single, uniform request flow that every feature in `eo.web` follows. There is no cross-feature communication at this layer — each page is a self-contained unit.

## Key Patterns and Architecture

### JSF Page Controller Pattern

Every feature in `eo.web` adheres to a strict two-class convention:

- **Bean class** (`*Bean`) — A lightweight POJO with a no-arg constructor, private fields, and public getters. It exposes data to the view via EL expressions (e.g., `#{aca001sFBean.value}`) but typically holds no setters. The bean acts as a conduit between the view and the controller, not as a domain model.
- **Logic class** (`*Logic`) — The page controller with an `execute()` method that handles user actions. It returns `void`; navigation is driven entirely by outcome mappings in `faces-config.xml` rather than by a return string.

### XML-Driven Wiring

All wiring is done through XML configuration rather than annotation-based discovery. Each feature is referenced by multiple configuration files:

- **`faces-config.xml`** — Registers managed beans and defines navigation rules.
- **Custom XML configs** (e.g., `WEBGAMEN_FULL_ACA001.xml`, `x33S_ACA001.xml`, `external-refs.xml`) — Reference both bean and logic classes, likely representing different deployment profiles, feature flags, or environment-specific toggles.

A single feature like `ACA001SF` is wired into at least five distinct XML configurations, indicating it is active across multiple deployment profiles. This broad wiring means any change to a bean name, method signature, or visibility modifier requires coordinated updates across all affected configuration files.

### Minimal Data Model

Features in this module tend to be data-light. A bean might hold a single `String` field with no setter — just enough state for the view to render and the logic class to act upon. This is intentional: the web layer's job is rendering and dispatch, not domain modeling.

### Parallel Feature Isolation

Feature packages under `webview` are completely independent. They do not import from or depend on sibling packages, and there is no shared state or coordination between pages at the web layer. This isolation is by design, making each feature a drop-in unit that can be added, removed, or modified without ripple effects on other features.

```mermaid
flowchart LR
    browser["Browser"] --> jsp["JSP/JSF View"]
    jsp --> bean["Bean"]
    jsp --> logic["Logic"]
    bean --> xml["XML Config"]
    logic --> xml
    xml --> next["Next View"]
```

## Dependencies and Integration

### Internal Dependencies

- **JSF framework** — Classes in this module depend on the JavaServer Faces API for managed bean semantics, EL resolution, and the `faces-config.xml` lifecycle.
- **Shared web infrastructure** — The `eo.web` tier likely contains shared components such as filters, servlets, or interceptors. Feature packages within `webview` are self-contained and do not import from sibling packages, but they consume infrastructure provided by the parent web tier.

### External Configuration

Each feature package is referenced by multiple XML configuration files. The `ACA001SF` module alone is wired into at least five distinct configs:

| Configuration File | References |
|---|---|
| `faces-config.xml` | Managed bean registration |
| `WEBGAMEN_FULL_ACA001.xml` | Bean + Logic |
| `WEBGAMEN_ACA001010PJP.xml` | Bean + Logic |
| `x33S_ACA001.xml` | Bean + Logic |
| `external-refs.xml` | Logic |

This breadth of wiring is a hallmark of the module: features are **active across multiple deployment profiles**, and any change requires coordination across all configuration contexts.

### Request Flow

The full request flow through the `eo` presentation layer:

1. A user navigates to a JSP page (e.g., `FULL_ACA001010PJP.jsp`).
2. JSF instantiates the managed bean and makes it available via EL.
3. The JSP renders using data from the bean.
4. User actions dispatch to the logic class's `execute()` method.
5. Navigation outcomes are resolved by `faces-config.xml` rules, directing the user to the next view.

## Notes for Developers

- **Empty method bodies are common.** Logic classes (e.g., `ACA001SFLogic.execute()`) may currently have no implementation. This is likely scaffolding or a placeholder — if you are adding functionality to a webview page, `execute()` is the correct entry point.
- **Bean fields may be read-only.** Some beans expose only getters, not setters. If you need to set a bean field from the logic class, you will need to add a setter or pass the bean by reference.
- **XML wiring is pervasive.** Each sub-package is referenced by multiple XML configuration files. Before changing a bean name, method signature, or visibility modifier, verify all XML references that would be affected.
- **Two source trees.** Some classes appear in both the main source tree (`full-fixture-codebase`) and a stubbed/unresolved source tree (`xml-unresolved-fqn`). Confirm which version is active in your build configuration.
- **Adding a new feature.** To create a new webview page, follow the existing pattern: create a sub-package with a `*Bean` class (view state) and a `*Logic` class (action handler), then register both in `faces-config.xml` and the relevant custom XML configs.
- **No cross-feature coordination.** Feature packages are independent — they do not import from or depend on sibling packages. This isolation is intentional but means there is no shared state or coordination between pages at the web layer.