# Eo

## Overview

The `eo` package is the top-level presentation layer of the application, responsible for rendering HTML responses to incoming HTTP requests. It follows a Java-based MVC architecture built on JSP pages, JavaBeans for data transport, and logic classes for request processing. The module is designed for a Japanese-market application (evidenced by files like `ShiftJis001.jsp`) and organizes its functionality into sub-packages, each following a consistent Bean-Logic pairing convention.

At the parent level, `eo` itself is an organizational shell — it declares no source files or classes directly. All concrete implementation is delegated to sub-module directories beneath it, the only one currently indexed being `eo.web.webview`. This structure means `eo` serves as the namespace root that groups the application's web-facing screens and shared rendering components.

## Sub-module Guide

### `eo.web` — Web Presentation Layer

`eo.web` is the web presentation layer. It sits between the browser and any downstream business logic, providing scoped, page-ready data containers that JSP pages access via `<jsp:useBean>`. Every functional sub-module within `web` declares a paired `Bean` (data carrier) and `Logic` (request handler), registered through XML configuration and consumed by JSP pages.

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

`webview` is the only indexed sub-module within `eo.web`. It provides the foundational rendering infrastructure that multiple JSP pages rely on. Its core building block is the `ACA001SF` sub-module, which defines:

- **`ACA001SFBean`** — A lightweight JavaBean holding a single `String value` property. It is the most widely consumed component in the web layer, referenced by five distinct JSP pages (`ACA001010PJP.jsp`, `FULL_ACA001010PJP.jsp`, `ShiftJis001.jsp`, `usebean.jsp`, and at least one more).
- **`ACA001SFLogic`** — A stub controller class with an empty `execute()` method. It is wired only where more complex orchestration is needed (e.g., `FULL_ACA001010PJP.jsp`).

**Relationship**: The parent `eo.web` module has zero indexed source files — all implementation lives at the sub-module level. New screens are added as new sub-modules within `webview` (or future sub-packages), each following the Bean-Logic pattern established by `ACA001SF`. `ACA001SFBean` serves as a shared, reusable component that multiple screens reference for simple data display, while `ACA001SFLogic` is invoked selectively where processing logic is required.

## Key Patterns and Architecture

### Bean-Logic Separation

Every sub-module follows a consistent two-class MVC split. The Bean carries data to the view, and the Logic handles request processing:

```mermaid
flowchart TD
    WEB["Web Presentation Layer (eo.web)"] --> WEBVIEW["webview Sub-module"]
    WEBVIEW --> BEAN["ACA001SFBean - Data Carrier"]
    WEBVIEW --> LOGIC["ACA001SFLogic - Controller"]
    BEAN --> JSP["JSP View Pages (5 pages)"]
    LOGIC --> JSP
    WEBVIEW --> XML["XML Config: WEBGAMEN_FULL_ACA001.xml"]
    XML --> BEAN
    XML --> LOGIC
```

1. **Bean** — A JavaBean declared as a scoped variable via `<jsp:useBean>`. Exposes getters for the data the view needs to render. Deliberately lightweight.
2. **Logic** — The controller. Invoked from the JSP to execute request-handling logic via `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 bean and logic (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 --> BEANINST["JSP instantiates Bean via useBean"]
    CFG --> LOGICINV["JSP invokes Logic.execute()"]
    BEANINST --> READ["JSP reads Bean properties"]
    LOGICINV --> READ
    READ --> 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` |

`ACA001SFBean` 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 `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` 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` module currently has zero indexed source files — all implementation lives within sub-module directories. Focus development within individual sub-module packages.
- **Japanese market target**: File naming conventions (e.g., `ShiftJis001.jsp`) suggest the application targets Japanese users. Take care with character encoding when adding new pages or modifying existing beans.