# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a webview subsystem within the broader `eo.web` hierarchy. It serves as a container for Struts-style MVC components that power specific web pages in the application. Each child sub-package under `webview` encapsulates the complete request-handling stack for a single page: a view-model bean, a logic/controller class, XML-based Struts routing configuration, and a JSP template.

At present, the package is lightly populated. The primary known sub-package is `ACA001SF`, which implements a minimal "Futurity" view page using the standard Struts `Action`/`FormBean`/`JSP` pattern. Most classes appear to be skeletal or stub implementations — the logic methods contain empty bodies and beans expose limited property access — suggesting this area of the codebase may be in early development, archived, or awaiting feature expansion.

## Sub-module Guide

### ACA001SF

**Source code:** [`eo.web.webview.ACA001SF`](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/)

The `ACA001SF` sub-package is the only documented child module at this level. It provides the full MVC stack for a single web page:

- **`ACA001SFBean`** — A JavaBean acting as the view-model. It exposes a single nullable `String` property, `value`, via a getter. There is no setter defined, so the value must be populated externally (typically by the logic class).
- **`ACA001SFLogic`** — The controller class, labeled in its Javadoc as "Futurity view logic." It follows the Struts `Action.execute()` convention but currently has an empty method body.
- **`WEBGAMEN_FULL_ACA001.xml`** — Struts XML configuration that maps the `ACA001SF` action name to the logic class.
- **`FULL_ACA001010PJP.jsp`** — The JSP view that renders the page by reading from the bean's `value` property.

This sub-package appears to be a scaffold for a "Futurity"-branded feature. The "Futurity" label in the class comment may indicate a domain-specific project or client-facing brand name.

## Key Patterns and Architecture

### Struts MVC Layout

The `webview` hierarchy adheres to the classic Apache Struts 1.x MVC convention:

1. **Request arrives** → the Struts XML config (`WEBGAMEN_FULL_ACA001.xml`) routes the action name to a logic class.
2. **Logic executes** → `execute()` performs any business logic and populates the bean.
3. **Bean holds data** → the view-model bean exposes properties that the JSP reads via JavaBean conventions.
4. **JSP renders** → the `.jsp` template produces the HTML response.

```mermaid
flowchart LR
    User["User / Browser"] --> XML["Struts XML Config"]
    XML --> Logic["Logic.execute()"]
    Logic --> Bean["View Bean"]
    Bean --> JSP["JSP Template"]
    JSP --> User
```

### Empty-Body Logic Pattern

A notable pattern across the known classes is the empty `execute()` method in `ACA001SFLogic`. This suggests either:

- The page is rendered without backend computation (a static template with data injected later).
- The implementation is incomplete and awaiting business logic.
- The bean may be pre-populated via a framework-level interceptor or decorator rather than directly in the logic class.

### Bean Property Discipline

The `ACA001SFBean` class demonstrates an asymmetry: it exposes a `getValue()` getter but defines no `setValue()` setter. In standard Struts usage, the form-bean properties are populated by the framework (from request parameters) or by the action logic. The absence of a setter implies the value is expected to be injected programmatically, which is unusual for a standard HTML form-backed bean and may indicate this bean is primarily a **write-once output model** rather than a request-driven form.

### No Child Sub-packages

The `webview` package itself contains no nested sub-packages beyond the individual module directories like `ACA001SF`. Each page-level module lives as a flat sub-package directly under `webview`, with no further decomposition. This keeps the hierarchy shallow and makes it easy to locate all files for a given page.

## Dependencies and Integration

### Inbound Dependencies

| Consumer | Relationship |
|---|---|
| Struts XML config files (e.g., `WEBGAMEN_FULL_ACA001.xml`) | Map action names to `*Logic` classes |
| JSP views (e.g., `FULL_ACA001010PJP.jsp`) | Read from `*Bean` properties |

### Outbound Dependencies

The known classes (`ACA001SFBean`, `ACA001SFLogic`) have **no Java-level package imports** beyond the standard Java library. This is consistent with the minimal/stub nature of these classes. When features are added, they will likely pull in Struts framework classes (`org.apache.struts.action.Action` or similar) and possibly domain or persistence packages.

### Position in the Broader System

`eo.web.webview` sits as a sub-package of `eo.web`, which is itself a sub-package of the root `eo` domain. The `web` parent likely houses additional web-facing packages (such as APIs, static resources, or other webview groups). The `webview` package specifically handles **user-facing page rendering** through the Struts MVC stack.

## Notes for Developers

- **Expect stub implementations.** The classes in this package appear to be scaffolds with empty method bodies. Before building on them, verify whether real logic should already exist or if the skeleton is intentional.
- **Struts convention matters.** The naming (`*Logic`, `*Bean`, `execute()`) strongly signals Struts 1.x. If the project has migrated from Struts or uses a different action framework, the XML config should be cross-referenced to confirm the routing layer.
- **"Futurity" as a domain label.** The comment on `ACA001SFLogic` references "Futurity." If multiple `*SF` packages exist with similar labeling, they may share a domain model or be part of a client-branded feature set.
- **Bean setter gaps.** Several beans (including `ACA001SFBean`) expose getters without setters. If you need to modify a bean's value from your own code, you will need to add a setter method explicitly.
- **No automated inventory.** The code index reports zero source files and zero classes for this module, likely because the indexing scope did not cover this package. The documentation here is derived from manual scanning and the child module wiki page. If the index is authoritative, some of these files may have been removed or relocated.