# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a Java EE web-tier subpackage within the `eo.web` hierarchy. It implements a classic MVC (Model-View-Controller) pattern using a JavaBean-backed action-logic model combined with JSP views. Each webview subpackage (e.g., `ACA001SF`) typically contains:

- A **Bean** class that carries view-scoped state as a simple POJO.
- A **Logic** class that defines the entry-point `execute()` method, acting as the controller that prepares data before rendering.
- An **XML configuration** file that wires the bean and logic together and maps URL patterns.
- One or more **JSP view pages** that render the HTML output using standard JSP EL expressions.

This module serves as a thin abstraction layer between business data and the browser. The framework handles request routing, bean lifecycle management, and view forwarding; individual subpackages fill in the data-loading and business-rule logic within their respective `execute()` methods.

## Sub-module Guide

The package currently contains the following child sub-package:

### ACA001SF — Futurity Web View

`ACA001SF` handles a Futurity-related web view. It is the simplest example of the webview pattern in this package:

- **`ACA001SFBean`** — A minimal POJO holding a single `String value` field with a `getValue()` getter. The bean is intentionally read-only, suggesting the value is populated by the logic class or framework before the JSP renders.
- **`ACA001SFLogic`** — The controller class carrying the javadoc "Futurity view logic." Its single `execute()` method is currently empty, indicating this is either a stub awaiting business logic, a no-op for a static view, or a template base class for extension.
- **`WEBGAMEN_FULL_ACA001.xml`** — The XML configuration that wires both the bean and logic class and maps URL patterns to the controller.
- **`FULL_ACA001010PJP.jsp`** — The JSP view that renders the HTML, accessing bean properties via JSP EL.

**Relationship to other webviews:** This sub-package follows the same pattern used by every other view in the `eo.web.webview` tree. Each view is independent — there are no shared logic classes or cross-view bean composition visible in this package. The XML config is the single point of wiring for each view. If additional sub-modules are added, they would follow this same convention: a Bean, a Logic, XML config, and JSP view, each self-contained and isolated.

## Key Patterns and Architecture

### Standard MVC Flow

Every webview in this package follows the same request lifecycle:

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

```mermaid
flowchart TD
    WEBVIEW["eo.web.webview
(webview package)"]
    ACA001SF["ACA001SF
(Futurity webview)"]

    WEBVIEW --> ACA001SF

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

    XML_CONFIG -->|wires to| LOGIC
    XML_CONFIG -->|configures| BEAN
    LOGIC -->|invokes| EXECUTE["execute()"]
    BEAN -->|holds| VALUE["value : String"]
    LOGIC -->|sets / uses| BEAN
    XML_CONFIG -->|routes to| JSP
    LOGIC -->|forwards to| JSP
    BEAN -->|exposes| JSP
```

### Design Decisions

- **Minimal bean shape.** Beans carry only the fields the JSP actually needs. This reduces coupling between layers and keeps the view model focused on presentation concerns.
- **Empty execute() as a template.** The absence of logic in `ACA001SFLogic.execute()` is not necessarily a bug — it follows the common pattern of stub classes that are filled in during feature development or subclassed for derived behavior.
- **JavaBeans conventions are critical.** The getter naming (`getValue()` vs `getValue`) determines whether JSP EL `${value}` resolves correctly. This is a framework contract that must not be changed without updating all consumers.
- **Single field, single purpose.** The `String value` field in `ACA001SFBean` is intentionally generic. Its meaning (title, message, code, identifier) can only be determined by examining the consuming JSP or the XML config that populates it.

### No Inter-Module Communication

Each webview sub-module is self-contained. There is no cross-view bean sharing, shared logic inheritance chain, or central data aggregator visible in this package. The only integration point is the shared XML configuration framework.

## Dependencies and Integration

### Outbound Dependencies

- **Java SE only** — The module uses standard Java types (`String`, class definitions) with no internal dependencies within the `eo.web.webview` tree.
- **No package-level imports** have been identified beyond the framework base types.

### Inbound / Integrating Dependencies

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

The XML configuration file is the central wiring point. It declares the bean's scope, connects the logic class, and defines the URL-to-view mapping. This keeps the Java classes decoupled from routing concerns.

### Framework Integration

This module integrates with the broader `eo.web` application framework through:

- **Action/interceptor chain** — The `execute()` method is the standard entry point expected by the framework's routing mechanism.
- **JSP EL resolution** — Bean properties are exposed to views through strict JavaBeans naming conventions.
- **XML-based configuration** — Routing and bean scoping are declarative, not code-based, allowing configuration changes without recompilation.

## Notes for Developers

- **Implementing logic.** If you are adding business logic to a view, start with the `execute()` method in the Logic class. Populate the Bean's fields there before the JSP renders.
- **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.
- **Multiple JSP consumers.** `ACA001SFBean` is referenced by 3 JSP views. Any changes to its shape (fields, getters) must be backward-compatible with all consumers.
- **Futurity domain context.** The `ACA001SFLogic` javadoc references "Futurity," which likely refers to a business domain concept in the broader application. Check surrounding packages or product documentation for domain context before making changes.
- **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 or left as a static display.
- **Adding new views.** New webviews should follow the existing pattern: create 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.