# Eo / Web / Webview

## Overview

The `eo.web.webview` module is the web-viewing layer of the Futurity web application. It houses Struts 1.x MVC components responsible for rendering HTTP request responses as HTML via JSP pages. Each sub-module within this package corresponds to a distinct view page or user-facing screen, and follows a consistent pattern: a Struts action logic class (the controller), a data-carrying bean (the model), XML action mappings (the router), and JSP templates (the view).

This appears to be a scaffolded set of view components rather than a fully populated application — many of the logic classes are empty method stubs, and beans expose minimal fields. The module provides the structural wiring (Struts configuration, bean contracts, JSP references) needed to scaffold production-ready view pages.

## Sub-module Guide

### ACA001SF — Futurity View Page Scaffold

**Path**: `eo.web.webview/ACA001SF`

ACA001SF is the primary sub-module in this area. It implements a classic Struts 1.x MVC flow for a single view page, comprising:

- **`ACA001SFLogic`** — The Struts action handler. It receives HTTP requests dispatched by the Struts `ActionServlet`, performs business logic (currently a no-op stub), and prepares the bean for the view.
- **`ACA001SFBean`** — The data carrier (form bean). It exposes a single `String value` field via `getValue()`, which JSP pages read to render content. This bean is the most widely referenced class in the sub-package, consumed by 7 JSP views.
- **`WEBGAMEN_FULL_ACA001.xml`** — The Struts XML action mapping that ties the request dispatch to `ACA001SFLogic` and instantiates `ACA001SFBean`.

The sub-module follows a standard Struts data flow:

```mermaid
flowchart LR
    JSP["JSP View Page"]
    BEAN["ACA001SFBean"]
    LOGIC["ACA001SFLogic"]
    XML["WEBGAMEN_FULL_ACA001.xml"]

    XML --> LOGIC
    XML --> BEAN
    JSP --> BEAN
    LOGIC --> BEAN
```

The flow works as follows:

1. A request arrives at the Struts `ActionServlet`, which consults the XML mapping (`WEBGAMEN_FULL_ACA001.xml`) to determine which logic class handles it.
2. The logic class (`ACA001SFLogic`) processes the request. In production, this would populate the bean with data derived from business logic or database queries.
3. The populated bean is placed in request or session scope.
4. The JSP view page reads from the bean (typically via `bean.getValue()`) to render HTML content.

ACA001SF serves as the template and reference implementation for how additional view pages should be structured within this module.

## Key Patterns and Architecture

### Struts 1.x MVC Triad

Every sub-module in `eo.web.webview` adheres to the Struts 1.x MVC pattern with three layers:

- **Model**: A JavaBean (`*Bean` classes) that carries data between the controller and view. Beans follow standard JavaBeans conventions — private fields, public getters and setters — enabling JSP EL access.
- **Controller**: An action logic class (`*Logic` classes) implementing Struts action handling. The `execute()` method is the entry point.
- **View**: JSP pages that read from the bean to render HTML.

### Request Dispatch via XML Configuration

The Struts action configuration XML files serve as the central routing layer. Each XML mapping file references both the bean (for instantiation) and the logic class (for request dispatch), acting as the single point of configuration that ties a URL pattern to the controller logic.

### Bean-Centric Data Flow

Beans are the most widely consumed artifacts in this module. In ACA001SF alone, `ACA001SFBean` is referenced by 7 JSP views and 1 XML configuration, while the logic class is referenced by fewer consumers. This reflects the Struts convention where the bean is the shared state object visible across multiple views and the controller.

### Stub-First Development

The codebase follows a stub-first pattern: logic classes define the `execute()` method signature but leave the body empty, and beans declare minimal fields. This appears intentional — the structural scaffolding (class names, XML mappings, JSP references) is in place, and production development fills in the logic and data fields incrementally.

## Dependencies and Integration

### Internal Dependencies

- **Struts 1.x framework**: The module relies on the Struts action lifecycle, action servlet dispatch, and XML action configuration. All request routing flows through Struts configuration files.
- **JSP views**: Multiple JSP pages consume bean data. In ACA001SF, 7 JSP files reference the bean, including `FULL_ACA001010PJP.jsp`, `ACA001010PJP.jsp`, and `ShiftJis001.jsp`.

### External Dependencies

- The logic and bean classes do not import any external frameworks beyond standard Java libraries and Struts APIs. The logic classes are intentionally decoupled from business logic in their current form.

### Cross-Module Connections

No cross-module relationships were detected in the index. This module appears to be self-contained, with its dependencies scoped to the Struts framework and the JSP view technology.

### Encoding Considerations

One of the consuming JSP files, `ShiftJis001.jsp`, includes "ShiftJis" in its name, suggesting this view (or views in this module generally) may serve Japanese locale contexts where Shift_JIS character encoding is required.

## Notes for Developers

- **This is a scaffold**: The module provides structural patterns rather than production-ready business logic. `execute()` methods are empty stubs, and beans expose minimal fields. Production development should fill these in with real logic.
- **Adding new data fields**: To extend a view's data model, add fields to the corresponding `*Bean` class with both getter and setter methods. The logic class should populate these fields in `execute()` before forwarding to the JSP.
- **Bean convention matters**: The bean must follow JavaBeans conventions (private fields, public getters/setters) for JSP EL and Struts tag libraries to work correctly.
- **XML mapping is the single point of truth**: Changes to class names, method signatures, or bean references require updating the XML configuration file. The XML is the central wire-up point between the servlet container, the action logic, and the data model.
- **Locale awareness**: When creating new view pages for international markets, be aware of character encoding requirements. The presence of `ShiftJis001.jsp` indicates at least one Japanese locale use case.
- **Multiple JSP consumers**: A single bean may be consumed by multiple JSP pages with different layouts or content requirements. The bean provides the data, and each JSP decides how to render it.