# Eo / Web

## Overview

The `eo.web` module is the presentation layer of the application, built on **JavaServer Faces (JSF)**. It provides the server-side rendering and action dispatch that bridge the user-facing views (JSP/JSF pages) with the business processing logic below. In this codebase, it functions as a collection of self-contained feature pages, each wired into the JSF navigation framework through `faces-config.xml` and related XML configuration files.

The module follows a **Page Controller pattern** adapted for JSF: each feature area gets its own sub-package containing a managed bean (for view state) and a logic class (for action handling). This uniform structure makes the web layer predictable and consistent — adding a new page means following the same Bean/Logic convention and registering it in the relevant XML configs.

At a high level, the web module exists to answer two questions for every page the user might interact with: (1) **what data does the view need to render?** (answered by the Bean) and (2) **what happens when the user triggers an action?** (answered by the Logic class).

## Sub-module Guide

The `eo.web` module contains one sub-module:

- **[`Webview`](eo/web/webview.md)** — The core webview sub-package that implements the server-side rendering and action dispatch for web-facing features. It is the only child in `eo.web` and serves as the bridge between JSP/JSF views and the application's business logic.

### How the sub-modules relate

The `webview` module is itself decomposed into feature-specific sub-packages. Within webview, each feature (such as `ACA001SF`, the "Futurity" page) is **independently wired** — there is no shared abstraction layer or cross-talk between feature packages. They all follow the same uniform pattern (Bean + Logic), but they do not import from or depend on sibling packages.

This means the `eo.web` package as a whole is essentially a **collection of parallel, self-contained feature pages** that share a common architectural convention but do not coordinate with each other at runtime.

```mermaid
flowchart TD
    user["User / Browser"] --> jsp["JSP/JSF View"]
    jsp --> bean["Managed Bean"]
    jsp --> logic["Logic Class"]
    logic --> fc["faces-config.xml"]
    bean --> fc
    fc --> outcome["Navigation Outcome"]
    outcome --> jsp
```

The diagram above captures the core request flow that every feature in `eo.web` follows: a user request lands on a JSP/JSF view, which reads state from a managed bean and dispatches actions to a logic class. Navigation outcomes are resolved by `faces-config.xml` rules.

## Key Patterns and Architecture

### JSF Page Controller Pattern

Every feature in `eo.web` adheres to the same two-class pattern:

- **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 is a conduit, not a domain model.
- **Logic class** (`*Logic`) — The page controller with an `execute()` method that handles user actions. It returns `void`; navigation is driven by outcome mappings in `faces-config.xml` rather than a return string.

### XML-Driven Wiring

All wiring happens through XML configuration rather than annotation-based discovery:

- **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, suggesting feature flags, deployment profiles, or environment-specific toggling.

A single feature like `ACA001SF` can be wired into **five distinct XML configurations**, indicating it is active across multiple deployment profiles or feature flags. This broad wiring means that 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 simplicity is intentional: the web layer's job is rendering and dispatch, not domain modeling.

```mermaid
flowchart LR
    browser["Browser"] --> jsp["JSP/JSF View"]
    jsp --> bean["Bean: ACA001SFBean"]
    jsp --> logic["Logic: ACA001SFLogic"]
    bean --> xml["faces-config.xml"]
    logic --> xml
    xml --> redirect["Next View"]
```

## Dependencies and Integration

### Internal Dependencies

- **JSF framework** — The 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 do consume infrastructure provided by the parent web tier.

### External Configuration

Each feature package is referenced by multiple XML configuration files. The `ACA001SF` module 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.web` module:

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.

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