# Eo / Web / Webview

## Overview

The `eo.web.webview` package serves as the web view rendering layer of the application. It implements a minimal MVC (Model-View-Controller) architecture using JavaBeans for data transport and logic classes for request processing, with JSP pages as the view tier. This layer sits between the presentation (JSP) and business logic, providing scoped, page-ready data containers that JSP pages can access via `<jsp:useBean>`.

The package follows a Struts-style convention where each functional sub-module provides a paired `Bean` (data carrier) and `Logic` (request handler), coordinated through XML configuration files and consumed by JSP view pages. While the overall module structure is still being fleshed out — indexed class and method counts at the parent level are zero — the sub-modules that do exist follow a consistent pattern.

## Sub-module Guide

### ACA001SF — View Rendering Scaffold

The `ACA001SF` sub-module provides the foundational MVC pair used by several JSP pages across the application. It consists of:

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

This module is referenced by the configuration file `WEBGAMEN_FULL_ACA001.xml` and consumed by five JSP pages: `ACA001010PJP.jsp`, `FULL_ACA001010PJP.jsp`, `ShiftJis001.jsp`, `usebean.jsp`, and others. The broad usage across pages suggests it is intended to be a shared building block, even though its implementation is currently minimal.

## Key Patterns and Architecture

### Bean-Logic Separation

The consistent pattern across sub-modules is a two-class MVC split:

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

1. **Bean** — Holds data as a scoped JavaBean (typically via `<jsp:useBean>`). Provides getters for reading; setters may be absent. This appears to be a deliberate lightweight choice, carrying only what the view needs to display.
2. **Logic** — Acts as the controller. Receives the request, performs any needed processing via `execute()`, then delegates to a JSP view. Currently stubbed in the existing sub-module.
3. **JSP View** — Reads the bean's properties and renders HTML. Pages like `FULL_ACA001010PJP.jsp` invoke both the bean (for data) and the logic class (for orchestration).

### Configuration-Driven Registration

Beans and logic classes are declared in XML configuration files (e.g., `WEBGAMEN_FULL_ACA001.xml`), which makes them available for JSP pages to reference. This centralizes the wiring and allows pages to remain decoupled from concrete class instantiation.

### Request Flow

The typical request flow across sub-modules proceeds as follows:

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

1. Configuration declares the bean and logic classes.
2. JSP pages instantiate the bean as a scoped variable (request, session, or page scope).
3. JSP pages optionally invoke the logic class's `execute()` method.
4. The JSP reads the bean's properties and renders the response.

## Dependencies and Integration

### Inbound

| 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 sub-module is heavily consumed by JSP pages (five distinct consumers for `ACA001SFBean` alone), indicating it is a shared component within the view layer.

### External

At the package level, no external Java package imports are declared. The module relies on `java.lang.String` (implicitly available) and the standard JSP/Servlet API for `<jsp:useBean>` and request/response handling.

## Notes for Developers

- **Stub implementations**: The existing sub-module's `ACA001SFLogic.execute()` is an empty method, and `ACA001SFBean` has no setter for its `value` field. These are likely scaffolds awaiting feature implementation.
- **JavaBean completeness**: `ACA001SFBean` exposes `getValue()` but lacks `setValue(String)`. If any downstream page needs to modify the bean's state, the setter should be added.
- **Wide JSP surface area**: Because the bean is consumed by five JSP pages, any changes to the bean's API should be validated against all consumers to avoid breaking the view layer.
- **Consistent separation**: Maintain the bean-logic separation when adding new sub-modules. The Bean should carry data; the Logic should handle processing. This keeps the view layer simple and the architecture consistent with the broader codebase.
- **No indexed source at parent level**: The parent module currently has zero indexed classes, methods, or imports — all source is captured at the sub-module level. Focus work within individual sub-module directories.