# Eo / Web

## Overview

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 through a classic Java EE MVC stack. The primary technical capability it represents is request routing, view rendering, and view-state management — essentially the "presentation layer" that translates internal domain data into HTML served to end users.

Within `eo.web`, the `webview` subpackage is the sole documented child. It houses the individual view modules (such as `ACA001SF` for Futurity views) that together form the application's UI. Each view module is self-contained, following a consistent pattern of Bean (state), Logic (controller), XML config (routing), and JSP (view).

## Sub-module Guide

### eo.web.webview

The `webview` subpackage is the core of `eo.web`. It implements the MVC pattern where every web-facing feature is a standalone sub-package containing four artifacts:

| 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 is the shared XML configuration framework, which the application container uses to resolve requests to the correct controller. This isolation makes each view easy to understand in isolation, but also 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.

The `ACA001SF` webview (Futurity) is currently a skeleton: its `execute()` method is empty, suggesting it is either a stub awaiting business logic or a static view template. New webviews added to the package should follow this same four-artifact pattern.

## Key Patterns and Architecture

### Request Lifecycle

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

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

```mermaid
flowchart TD
    PKG["eo.web
(parent package)
Web application layer"]
    WV["eo.web.webview
(webview sub-package)
MVC web view components"]

    PKG --> WV

    ACA001SF["ACA001SF
(Futurity webview)
Bean + Logic + XML + JSP"]

    WV --> ACA001SF

    XML_CONFIG["WEBGAMEN_FULL_ACA001.xml
request wiring"]
    LOGIC["ACA001SFLogic
execute()"]
    BEAN["ACA001SFBean
String value"]
    JSP_VIEW["FULL_ACA001010PJP.jsp
HTML rendering"]

    XML_CONFIG -->|wires to| LOGIC
    XML_CONFIG -->|configures| BEAN
    LOGIC -->|invokes| BEAN
    BEAN -->|exposes to| JSP_VIEW
    LOGIC -->|forwards to| JSP_VIEW
```

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

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

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

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

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

### Data Flow

```mermaid
flowchart LR
    CLIENT["HTTP Client
Browser"]
    XML["XML Config
URL -> 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
```

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

### Inbound / 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.web` integrates with the broader application through:

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

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