# Eo / Web

## Overview

The `eo.web` package serves as the web presentation layer of the Futurity web application. It is responsible for rendering HTTP request responses as HTML through a Struts 1.x MVC architecture. Rather than handling business logic or data persistence directly, this package delegates those concerns outward and focuses on the view and request-dispatch responsibilities — receiving requests, wiring them to the correct controller logic, and rendering the appropriate JSP-based views.

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

## Sub-module Guide

### webview

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

The `webview` sub-module is the primary (and currently only) consumer-facing sub-module under `eo.web`. It implements the full Struts 1.x MVC triad for web request handling:

- **Model** — JavaBeans (`*Bean` classes) that carry data between controller and view. The `ACA001SFBean` is the most widely consumed artifact, referenced by 7 JSP views and 1 XML configuration.
- **Controller** — Action logic classes (`*Logic` classes) implementing Struts action handling. The `execute()` method is the entry point. Currently, `ACA001SFLogic` is a no-op stub.
- **View** — JSP pages that read from the bean to render HTML content. Multiple JSP files (e.g., `FULL_ACA001010PJP.jsp`, `ShiftJis001.jsp`) may consume a single bean for different layouts or rendering paths.

The Struts request flow works as follows:

1. A request arrives at the Struts `ActionServlet`, which consults the XML action mapping (`WEBGAMEN_FULL_ACA001.xml`) to determine which logic class handles it.
2. The logic class processes the request and populates the bean with data.
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.

```mermaid
flowchart LR
    Client["HTTP Client"]
    Servlet["ActionServlet"]
    XML["XML Action Mapping"]
    Logic["Logic Class"]
    Bean["Bean"]
    JSP["JSP View"]
    Response["HTML Response"]

    Client --> Servlet
    Servlet --> XML
    XML --> Logic
    XML --> Bean
    Logic --> Bean
    Bean --> JSP
    JSP --> Response
```

### Relationships

With only one sub-module currently, `webview` represents the entirety of the web package's scope. Its design — a stub-first, scaffolded approach — establishes the pattern that any future sub-modules in `eo.web` should follow. The ACA001SF implementation serves as the template and reference architecture for how additional view pages should be structured.

## Key Patterns and Architecture

### Struts 1.x MVC Triad

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

- **Model**: A JavaBean that carries data between the controller and view, following standard JavaBeans conventions (private fields, public getters and setters) for JSP EL access.
- **Controller**: An action logic class where the `execute()` method is the entry point. The method signature is defined, but bodies are intentionally left empty as stubs.
- **View**: JSP pages that read from the bean to render HTML. A single bean may be consumed by multiple JSP pages with different layouts.

### 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. Changes to class names or bean references require updating the XML.

### Bean-Centric Data Flow

Beans are the most widely consumed artifacts in the web package. In the ACA001SF sub-module alone, the bean is referenced by 7 JSP views and 1 XML configuration, while the logic class has 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 development pattern: logic classes define the `execute()` method signature but leave the body empty, and beans declare minimal fields. The structural scaffolding — class names, XML mappings, JSP references — is in place, and production development fills in the logic and data fields incrementally. This approach allows frontend and integration work to proceed in parallel with business logic implementation.

## Dependencies and Integration

### Internal Dependencies

- **Struts 1.x framework**: The package 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.

### External Dependencies

- The logic and bean classes import only standard Java libraries and Struts APIs. The logic classes are intentionally decoupled from business logic frameworks in their current form.
- External business logic, data access, and service layers are expected to be consumed through the logic classes' `execute()` methods once they are populated.

### Cross-Module Connections

No cross-module relationships were detected in the index. The module appears to be self-contained, with dependencies scoped to the Struts framework and the JSP view technology. In production, logic classes are expected to integrate with backend services and data access layers.

### Encoding Considerations

The presence of `ShiftJis001.jsp` indicates at least one Japanese locale use case where Shift_JIS character encoding is required. When creating new view pages for international markets, character encoding requirements should be considered.

## Notes for Developers

- **This is a scaffold**: The package 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 beyond the existing Shift_JIS 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.