# Eo / Web

## Overview

The `eo.web` package is the web presentation layer of the application. It renders HTML responses to incoming HTTP requests using a Java-based MVC architecture built on JSP pages, JavaBeans for data transport, and logic classes for request processing. The layer sits between the browser (JSP views) and any downstream business logic, providing scoped, page-ready data containers that JSP pages access via `<jsp:useBean>`.

The architecture follows a Struts-style convention: each functional sub-module declares a paired `Bean` (data carrier) and `Logic` (request handler), registered through XML configuration files and consumed by JSP pages. At the parent level, the module currently has zero indexed source files and classes — all implementation lives within sub-module directories (e.g., `eo.web.webview`), each of which follows this same two-class MVC split.

The web layer appears to be built for a Japanese-market application (evidenced by files like `ShiftJis001.jsp`), and its shared components are consumed across multiple pages, suggesting a modular approach to building distinct application screens.

## Sub-module Guide

### `eo.web.webview` — View Rendering Scaffold

The `webview` sub-package is the only sub-module currently indexed for `eo.web`. It provides the foundational rendering infrastructure that multiple JSP pages rely on for displaying data and processing requests.

Within `webview`, the `ACA001SF` sub-module is the core building block. It defines:

- **`ACA001SFBean`** — A lightweight JavaBean holding a single `String value` property. It acts as a scoped variable shared across five JSP pages, carrying data between the view and the logic layer.
- **`ACA001SFLogic`** — A stub controller class with an empty `execute()` method. It follows the standard pattern of receiving a request, performing processing, and delegating to a JSP view.

`ACA001SFBean` is consumed by five distinct JSP pages (`ACA001010PJP.jsp`, `FULL_ACA001010PJP.jsp`, `ShiftJis001.jsp`, `usebean.jsp`, and at least one more), making it the most-referenced component in the web layer. `ACA001SFLogic` is used by `FULL_ACA001010PJP.jsp` directly, indicating that the logic class is wired in only where more complex orchestration is needed.

**Relationship to the parent module**: All `eo.web` functionality is currently captured at the sub-module level. The parent module itself is an empty shell that delegates to `webview` (and any future sub-modules) for actual implementation. As new screens are added, new sub-modules will follow the Bean-Logic pairing established by `ACA001SF`.

## Key Patterns and Architecture

### Bean-Logic Separation

Every sub-module follows a consistent two-class MVC split:

```mermaid
flowchart TD
    JSP["JSP View Pages"] --> BEAN["Bean (Model)"]
    JSP --> LOGIC["Logic (Controller)"]
    BEAN --> DATA["String value"]
    LOGIC --> EXEC["execute()"]
```

1. **Bean** — A JavaBean declared as a scoped variable via `<jsp:useBean>`. Exposes getters for the data the view needs to render. Deliberately lightweight, carrying only what the screen displays.
2. **Logic** — The controller. Invoked from the JSP to execute request-handling logic (`execute()`), then delegates to a view. Currently a stub in all existing sub-modules.
3. **JSP View** — Reads bean properties and renders HTML. Some pages use only the bean (simple display), while others invoke both the bean and the logic class (orchestrated rendering).

### Configuration-Driven Registration

Beans and logic classes are declared in XML configuration files (e.g., `WEBGAMEN_FULL_ACA001.xml`). This centralizes wiring and keeps JSP pages decoupled from concrete class instantiation. To add a new screen, developers register the Bean and Logic classes in XML, then reference them from the JSP.

### Request Flow

```mermaid
flowchart TD
    REQ["Incoming Request"] --> CFG["XML Config: declare Bean + Logic"]
    CFG --> BEAN["JSP instantiates Bean via useBean"]
    CFG --> LOGIC["JSP invokes Logic.execute()"]
    BEAN --> RENDER["JSP reads Bean properties"]
    LOGIC --> RENDER
    RENDER --> RESP["HTTP Response: rendered HTML"]
```

1. The XML config file declares the Bean and Logic classes.
2. The JSP page instantiates the Bean as a scoped variable (request, session, or page scope).
3. The JSP optionally invokes `Logic.execute()` for processing.
4. The JSP reads Bean properties and renders the final HTML response.

## Dependencies and Integration

### Inbound Dependencies (consumers)

| Consumer | Uses |
|----------|------|
| `WEBGAMEN_FULL_ACA001.xml` | Declares `ACA001SFBean` and `ACA001SFLogic` |
| `ACA001010PJP.jsp` | Uses `ACA001SFBean` |
| `FULL_ACA001010PJP.jsp` | Uses `ACA001SFBean` and `ACA001SFLogic` |
| `ShiftJis001.jsp` | Uses `ACA001SFBean` |
| `usebean.jsp` | Uses `ACA001SFBean` |

The `ACA001SFBean` component is the most widely consumed artifact, appearing across five JSP pages. This breadth of usage suggests it is intended as a shared, reusable component within the view layer.

### External Dependencies

At the package level, no external Java imports are declared beyond the standard `java.lang.String` and the JSP/Servlet API (`<jsp:useBean>`, request/response). The module depends on the JSP engine for rendering and on XML configuration parsing for bean/logic registration.

### Cross-Module Context

No cross-module Java package imports have been detected — `eo.web` operates as a self-contained presentation layer. It does not import business-logic or data-access packages directly; any downstream processing would occur within the `Logic.execute()` methods once they are fully implemented.

## Notes for Developers

- **Stub implementations are common**: `ACA001SFLogic.execute()` is currently empty, and `ACA001SFBean` has no `setValue(String)` setter (only `getValue()`). These are scaffolds awaiting feature implementation.
- **JavaBean completeness**: If downstream pages need to modify a bean's state, add the corresponding setter. The current bean-logic split assumes data flows one direction (into the bean), but bidirectional flows may be needed for form submissions.
- **Wide JSP surface area**: `ACA001SFBean` is consumed by five JSP pages. Any changes to its API should be validated against all consumers to avoid breaking the view layer.
- **Follow the Bean-Logic pattern**: When adding new sub-modules, maintain the two-class separation. The Bean carries data; the Logic handles processing. This keeps the architecture consistent and the views simple.
- **Work at the sub-module level**: The parent `eo.web` module currently has zero indexed source files — all implementation lives within sub-module directories. Focus development within individual sub-module packages.