# Eo

## Overview

The `eo` package is the web presentation layer of the Futurity web application. It owns the Struts 1.x MVC architecture that renders HTTP requests as HTML, acting as the bridge between browser-based clients and the backend business logic of the system. Rather than handling domain logic or data persistence, `eo` focuses exclusively on request dispatch, data binding, and view rendering — receiving requests, routing them through Struts configuration, and producing HTML responses.

The package follows a **stub-first development** approach: structural scaffolding (class names, XML action mappings, JSP references) is in place, but logic classes contain empty `execute()` method bodies and beans declare only minimal fields. This allows frontend and integration work to proceed in parallel with business logic implementation.

At this time, `eo` contains a single sub-module — `eo.web` — which encompasses the full web presentation stack.

## Sub-module Guide

### eo.web

`eo.web` is the web package that implements the Struts 1.x MVC pattern. It is responsible for:

- **Request routing**: The Struts `ActionServlet` consults XML action mapping files (e.g., `WEBGAMEN_FULL_ACA001.xml`) to determine which logic class handles each incoming request.
- **Data binding**: JavaBeans (`*Bean` classes) carry data between the controller and view. The `ACA001SFBean` is currently the most widely consumed artifact, referenced by 7 JSP views and 1 XML configuration.
- **View rendering**: JSP pages read from beans (typically via `bean.getValue()`) to render HTML content. Multiple JSP pages can consume a single bean for different layouts or rendering paths.

Within `eo.web`, the `webview` sub-package implements the complete MVC triad. The `ACA001SF` flow serves as the template — all future view pages should follow the same pattern of XML mapping → logic class → bean → JSP view.

#### Request flow

```mermaid
flowchart TD
    subgraph ClientTier["Client Tier"]
        Client["HTTP Client"]
    end
    subgraph StrutsTier["Struts MVC"]
        Servlet["ActionServlet"]
        XML["XML Action Mapping"]
        Logic["Logic Class"]
        Bean["Bean"]
    end
    subgraph ViewTier["View Layer"]
        JSP["JSP View"]
        Response["HTML Response"]
    end
    Client --> Servlet
    Servlet --> XML
    XML --> Logic
    XML --> Bean
    Logic --> Bean
    Bean --> JSP
    JSP --> Response
```

#### Relationships

With only `webview` currently present, it represents the entirety of `eo`'s scope. Its stub-first design establishes the pattern that any future sub-modules should adopt. The `ACA001SF` implementation is the reference architecture for structuring new view pages.

## Key Patterns and Architecture

### Struts 1.x MVC Triad

Every sub-module under `eo` adheres to a three-layer MVC pattern:

| Layer | Responsibility | Artifact |
|-------|---------------|----------|
| **Model** | Carries data between controller and view | `*Bean` classes with private fields, public getters/setters |
| **Controller** | Processes requests, populates beans | `*Logic` classes with `execute()` entry point (currently empty stubs) |
| **View** | Renders HTML from bean data | JSP pages reading beans via Struts tag libraries |

### Bean-Centric Data Flow

Beans are the most widely consumed artifacts in the 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.

### XML-Driven Request Routing

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 dispatch), acting as the single point of configuration that ties a URL pattern to controller logic. Changes to class names or bean references require updating the XML configuration.

### Stub-First Development

Logic classes define the `execute()` method signature but leave the body empty, and beans declare only minimal fields. The structural scaffolding is in place; production development fills in logic and data fields incrementally.

## Dependencies and Integration

### Internal Dependencies

- **Struts 1.x framework**: All request routing flows through the Struts action lifecycle, action servlet dispatch, and XML action configuration files.
- **JSP views**: Multiple JSP pages consume bean data. In `ACA001SF`, 7 JSP files reference the bean.

### External Dependencies

- Logic and bean classes import only standard Java libraries and Struts APIs.
- External business logic, data access, and service layers are expected to be consumed through the logic classes' `execute()` methods once populated.

### Cross-Module Connections

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

### Encoding

The presence of `ShiftJis001.jsp` indicates at least one Japanese locale use case requiring Shift_JIS character encoding. International view pages should consider character encoding requirements from the start.

## 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**: 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**: Beans 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; each JSP decides how to render it.