# Eo

## Overview

`Eo` appears to be a very small, web-oriented package area whose current documented purpose is to host screen-level application wiring rather than shared domain services. The available evidence suggests that this area is organized around a framework-driven request flow: configuration routes a request to a screen logic class, the logic works with a bean that holds renderable state, and a JSP produces the final page.

At the index level, the module looks intentionally narrow. There are no resolved package dependencies, no indexed source files, and no detected cross-module relationships beyond the web-facing child page. That makes `Eo` look less like a broad subsystem and more like a thin integration boundary for web screens.

## Sub-module Guide

### [`web`](.codewiki/eo/web.md)

`web` is the only documented child area under `Eo`. It serves as the web-facing entry point for the package and appears to define how screen modules are structured in this part of the codebase.

The child documentation indicates that `web` centers on a single screen module, `webview`, which in turn contains one screen implementation, `ACA001SF`. The important relationship is not just containment, but role separation:

- `ACA001SFLogic` appears to handle the screen execution entry point.
- `ACA001SFBean` appears to carry the state that the screen renders.
- `WEBGAMEN_FULL_ACA001.xml` appears to wire the screen into the framework flow.
- `FULL_ACA001010PJP.jsp` appears to render the final page.

So `web` acts as the package-level composition point for a screen-oriented web flow. The logic, bean, XML, and JSP are coordinated pieces of one request lifecycle rather than independent features.

In practice, that means the child module is not just a folder of UI code. It appears to define the contract between framework routing, screen state, and page rendering. Because there are no other documented child modules, `web` also appears to establish the pattern that future web screens in `Eo` would follow.

## Key Patterns and Architecture

The architecture described by the child documentation appears to follow a conventional layered screen pattern:

1. A request is routed by XML configuration.
2. The framework invokes a logic class for screen execution.
3. The logic class uses or populates a bean that represents view state.
4. The JSP renders that state into HTML.

This separation is the main structural idea visible in `Eo`:

- **Bean** for state exposed to the view
- **Logic** for execution and lifecycle handling
- **XML** for framework wiring
- **JSP** for presentation

That pattern suggests a deliberate preference for keeping UI state, action handling, and view rendering distinct. It also means that most behavior changes in this area likely span multiple artifacts, not just one Java class.

The package-level evidence reinforces that this is a lightweight web integration area. There is no sign of a shared domain service layer or cross-feature orchestration inside the indexed module. Instead, `Eo` appears to be organized around one screen flow at a time.

### Mermaid Diagram

```mermaid
flowchart TD
EoModule["Eo"] --> WebModule["web"]
WebModule --> WebviewModule["webview"]
WebviewModule --> ScreenAca001sf["ACA001SF"]
ScreenAca001sf --> ScreenBean["ACA001SFBean"]
ScreenAca001sf --> ScreenLogic["ACA001SFLogic"]
ScreenBean --> XmlConfig["WEBGAMEN_FULL_ACA001.xml"]
ScreenLogic --> XmlConfig["WEBGAMEN_FULL_ACA001.xml"]
ScreenBean --> JspView["FULL_ACA001010PJP.jsp"]
ScreenLogic --> JspView["FULL_ACA001010PJP.jsp"]
```

## Dependencies and Integration

The module index for `Eo` does not show resolved package dependencies or source-level imports, so the visible integration points are mostly framework artifacts rather than code-to-code dependencies.

The most explicit links from the child documentation are to these resources:

- [`WEBGAMEN_FULL_ACA001.xml`](.codewiki/eo/web/webview/WEBGAMEN_FULL_ACA001.xml) — the screen configuration that appears to connect the request lifecycle to the logic class
- [`FULL_ACA001010PJP.jsp`](.codewiki/eo/web/webview/FULL_ACA001010PJP.jsp) — the JSP that appears to render the screen

Taken together, these suggest that `Eo` integrates with the rest of the system through conventional web-framework wiring rather than through direct package dependencies. The Java classes provide the screen behavior, while XML and JSP define how the framework invokes and displays that behavior.

## Notes for Developers

- This area appears to be screen-oriented rather than domain-oriented, so any change may require updates across Java, XML, and JSP artifacts.
- The available documentation is sparse, so framework conventions likely matter more here than local implementation details.
- `ACA001SFLogic.execute()` appears to be the main execution hook for the documented screen, but the child page does not show substantial business logic yet.
- `ACA001SFBean` appears to be the view-state carrier, so initialization and data population may happen outside the documented files.
- Because `web` is currently the only documented child, additions in this area will likely set the pattern for future screens under `Eo`.
- The documentation suggests a thin integration boundary, so developers should check the configuration files as carefully as the code when troubleshooting behavior.