# Eo

## Overview

The `eo` package is the top-level root package of the application. It represents a browser-facing web application built on a classic Java EE MVC stack. The primary capability of `eo` is user-facing presentation: it receives HTTP requests, routes them through an XML-declared configuration layer to controller logic, prepares data in view-scoped beans, and renders HTML responses via JSP templates.

`eo` contains one documented sub-package — `eo.web` — which is the sole web-tier package and the functional heart of the entire system. Every user-facing feature flows through this single branch.

## Sub-module Guide

### eo.web

The `eo.web` package is the web-tier entry point of the `eo` application. It sits at the intersection of business logic and the browser, providing the HTTP-facing surface of the system. Its responsibility spans request routing, view rendering, and view-state management — everything that translates internal domain data into HTML served to end users.

#### eo.web.webview

Within `eo.web`, the `webview` subpackage is the core implementation. It houses all individual view modules (e.g., `ACA001SF` for Futurity views). Each webview follows a strict four-artifact pattern:

| Artifact | Role |
|---|---|
| **Bean** | A minimal POJO carrying view-scoped data (e.g., `ACA001SFBean` with a single `String value`). |
| **Logic** | The controller class (`ACA001SFLogic`) with an `execute()` method that prepares data before rendering. |
| **XML Config** | Declarative wiring file (e.g., `WEBGAMEN_FULL_ACA001.xml`) that maps URL patterns to the controller and configures bean scope. |
| **JSP View** | The HTML template (e.g., `FULL_ACA001010PJP.jsp`) that renders the response using JSP EL to read from the bean. |

**How they relate.** Each webview sub-package is an independent unit — there is no shared logic base class, no cross-view bean composition, and no direct communication between views. The only integration point across all webviews is the shared XML configuration framework, which the application container uses to resolve incoming requests to the correct controller. This isolation makes each view easy to understand in isolation but means there is no reusable abstraction layer for common view logic. If multiple views need the same data preparation, the Logic classes are duplicated rather than shared.

`eo` as a whole is flat at the top level: `eo.web` is the only documented child, and `webview` is the only documented grandchild. The entire web application functionality lives inside this one branch. New features are added by creating new sub-packages under `webview`, each following the same four-artifact pattern.

## Key Patterns and Architecture

### Request Lifecycle

Every webview in `eo.web` follows an identical, predictable request flow:

```
HTTP Request -> XML Config -> Logic.execute() -> Bean population -> JSP render
```

This uniformity means developers can reason about any feature by following a single pattern — locate the XML config for the URL, find the Logic class it points to, trace how it populates the Bean, and inspect the JSP for the output.

### Module Hierarchy

```mermaid
flowchart TD
    APP["eo
Application root
Namespace"]
    WEB["eo.web
Web application layer
HTTP-facing surface"]
    WV["eo.web.webview
MVC view components
Sub-package group"]

    APP --> WEB
    WEB --> WV
```

### Data Flow

```mermaid
flowchart LR
    CLIENT["HTTP Client
Browser"]
    XML["XML Config
URL to Logic mapping"]
    LOGIC["Logic.execute()
Data preparation"]
    BEAN["Bean
State holder"]
    JSP["JSP View
HTML template"]

    CLIENT -->|request| XML
    XML -->|dispatches| LOGIC
    LOGIC -->|populates| BEAN
    LOGIC -->|forwards| JSP
    BEAN -->|properties via JSP EL| JSP
    JSP -->|HTML response| CLIENT
```

### Design Decisions

- **Minimal beans.** Each Bean carries only the fields the JSP needs. This keeps the view model focused on presentation and reduces coupling to upstream logic. However, it also means that the meaning of a field like `String value` cannot be inferred from the Bean alone — you must read the consuming JSP or the XML config to understand its purpose.

- **No shared abstractions.** The design deliberately avoids inheritance or shared utility classes between views. This keeps each view self-documenting and isolated, but it also means common patterns (error handling, pagination, form validation) are likely duplicated across views rather than abstracted.

- **Single responsibility per file.** Each artifact in a webview sub-package has a single concern: the Bean holds data, the Logic controls flow, the XML declares wiring, and the JSP renders HTML. This makes it easy to locate changes but means small modifications can touch all four files.

- **JavaBeans naming is a hard contract.** JSP EL resolution depends on exact JavaBeans getter conventions (e.g., `getValue()` resolves to `${value}`). Changing a getter signature without updating all consumers will silently break the view with no compile-time error.

- **Empty execute() as a template.** The absence of implementation in `ACA001SFLogic.execute()` is a common pattern. It acts as a stub that feature developers fill in during implementation, or as a subclassable base for derived behavior. An empty `execute()` is not necessarily a bug — it may be intentional for a static display view.

## Dependencies and Integration

### Outbound Dependencies

- **Java SE only** — The documented webview classes use standard Java types (`String`, class definitions) with no package-level imports beyond the framework base types.
- **No intra-package dependencies** — There are no cross-module relationships or import patterns detected within `eo.web`. Each sub-package is fully self-contained.

### Integrating Dependencies

| Consumer | Role |
|---|---|
| `WEBGAMEN_FULL_ACA001.xml` | Declares the bean as a request/session-scoped managed bean; maps URL patterns to `ACA001SFLogic`. This is the central wiring point for the entire view. |
| `FULL_ACA001010PJP.jsp` | Renders the HTML view; accesses bean properties and logic results via JSP EL expressions. |

### Framework Integration

`eo` integrates with the broader application infrastructure through:

- **XML-based configuration** — Routing, bean scoping, and URL mappings are declarative rather than code-based. This allows configuration changes (e.g., changing a bean's scope from request to session) without recompilation.
- **JSP EL resolution** — Bean properties are exposed to views through strict JavaBeans naming conventions. The framework handles the bridge between the request scope and the JSP expression language.
- **Action/interceptor chain** — The `execute()` method is the standard controller entry point expected by the framework's routing mechanism. Other controllers or interceptors in the `eo.web` package may decorate or wrap this flow.

### Business Context

The `ACA001SFLogic` javadoc references "Futurity," which likely refers to a business domain concept within the broader `eo` application. This suggests the web tier is organized around specific business capabilities (e.g., Futurity, and potentially others not yet documented), with each capability getting its own view sub-package.

## Notes for Developers

- **Implementing logic.** Start in the `execute()` method of the Logic class. Populate the Bean's fields there before the JSP renders. The JSP has no server-side logic of its own — all computation should happen in the Logic class.

- **JavaBeans naming is non-negotiable.** The getter must follow `get` + capitalized field name exactly. Renaming without updating the JSP EL will silently break the view with no compile-time diagnostic.

- **Multiple JSP consumers.** A Bean like `ACA001SFBean` may be referenced by multiple JSP views. Any changes to its shape (fields, getters, type) must be backward-compatible with all consumers.

- **Adding new views.** New webviews should follow the existing four-artifact pattern: a Bean POJO, a Logic class with `execute()`, a corresponding XML config entry, and a JSP view. Keep the bean shape minimal and the logic method focused on data preparation.

- **Static view possibility.** If a view has no logic to implement, the empty `execute()` method may be intentional. The bean could be populated entirely by the XML framework (e.g., with static constants or request parameters) and left as a static display.

- **Debugging tip.** When a JSP renders blank or null values, check the XML config first to confirm the bean scope and URL mapping, then trace through the `execute()` method to verify the Bean is being populated before the forward to the JSP.

- **Domain knowledge matters.** The meaning of generic Bean fields (like `String value`) and the purpose of a webview can only be determined by reading the consuming JSP, the XML config, and any surrounding business-domain documentation. Don't assume the Java code tells the whole story.