# Eo

## Overview

`Eo` appears to be a small web-facing area of the codebase whose documented responsibility is to expose named screen flows through framework wiring rather than through a large set of reusable business services. Based on the available child documentation, this package serves as the boundary between Java-side view support and the external configuration and templates that actually activate and render screens.

The evidence suggests that `Eo` is intentionally thin. Instead of a deep internal hierarchy, the module seems to coordinate a small number of view flows, keeping the Java classes focused on being stable integration points for XML and JSP artifacts. In other words, this area appears to represent screen orchestration more than domain logic.

## Sub-module Guide

### `web`

[`web`](.codewiki/eo/web.md) is the only documented child area under `Eo`, and it represents the package's web integration surface.

The child documentation describes `web` as a web-facing module centered on webview wiring. Its main role is to connect Java view logic to configuration and presentation artifacts so that specific screens can be activated and rendered. That means `web` is not just a container for UI code; it is the layer that ties together the runtime entry points and the view implementation.

### `webview`

[`webview`](.codewiki/eo/web/webview.md) is the focused subsystem inside `web`. It centers on a single named flow, `ACA001SF`, which is documented as a paired unit:

- `ACA001SFBean` - a state holder for view data
- `ACA001SFLogic` - the logic entry point invoked by the framework

The relationship here is straightforward but important. The bean carries the screen state that the presentation layer needs, while the logic class provides the action hook that the web framework calls when the flow is reached. This appears to be a thin-view pattern in which the Java side supplies the contract for a screen, but the actual orchestration is spread across XML and JSP files.

The child page also shows external references that anchor the flow:

- `WEBGAMEN_FULL_ACA001.xml` - wires in `ACA001SFBean` and `ACA001SFLogic`
- `FULL_ACA001010PJP.jsp` - consumes `ACA001SFBean` and `ACA001SFLogic`

That makes `webview` the named integration endpoint for a specific screen path. The XML starts the flow, the Java classes provide the data and behavior contracts, and the JSP renders the result.

## Key Patterns and Architecture

### Flow-oriented screen integration

The documented structure suggests a flow-based web architecture:

1. A configuration artifact names a logic class.
2. The framework invokes that logic when the screen or action is reached.
3. A bean carries the data needed by the view layer.
4. A JSP renders the UI using that state.

This appears to be a convention-driven design. The module's purpose is not to implement complex algorithms, but to keep Java types, XML configuration, and presentation templates aligned.

### Bean and logic separation

`ACA001SFBean` and `ACA001SFLogic` illustrate a clean separation of responsibilities.

- The bean keeps state explicit and presentation-friendly.
- The logic class concentrates the framework entry point.

This separation makes the screen easier to extend without blending data shape and execution flow into one class. It also helps keep screen-specific code isolated from broader application concerns.

### Contract-first integration surface

No source files, package dependencies, or cross-module relationships were indexed directly for `Eo`. That absence suggests the index only captured the documentation surface, not the full implementation graph. Even so, the documented XML and JSP links make one thing clear: the package behaves like a contract boundary.

For developers, that usually means naming matters. Small changes to class names, flow names, or bean properties can affect the XML wiring and the JSP rendering contract.

## Dependencies and Integration

### External integration points

The documented flow integrates with two external artifacts:

- `WEBGAMEN_FULL_ACA001.xml` - uses `ACA001SFBean` and `ACA001SFLogic`
- `FULL_ACA001010PJP.jsp` - uses `ACA001SFBean` and `ACA001SFLogic`

These references place `Eo` at the edge between framework configuration and user-facing presentation. The XML appears to bind the flow into the runtime, while the JSP consumes the bean and logic contract to render the screen.

### Relationship to the wider system

This area appears to be one of the system's web entry points. Its value is in compatibility with the surrounding web stack rather than in broad internal reuse. The module likely supports a specific screen or screen family whose behavior is mostly orchestrated outside of the package itself.

### What the index does not show

The available evidence does not show resolved package dependencies, indexed source files, or additional child modules beyond `web`. As a result, the safest interpretation is that `Eo` is a small integration-oriented package whose behavior depends heavily on the surrounding web framework and view artifacts.

## Mermaid Diagram

```mermaid
flowchart TD
Eo["Eo"] --> Web["web"]
Web["web"] --> Webview["webview"]
Webview["webview"] --> ACA001SF["ACA001SF"]
ACA001SF["ACA001SF"] --> Bean["ACA001SFBean"]
ACA001SF["ACA001SF"] --> Logic["ACA001SFLogic"]
XML["WEBGAMEN_FULL_ACA001.xml"] --> Logic
JSP["FULL_ACA001010PJP.jsp"] --> Bean
JSP["FULL_ACA001010PJP.jsp"] --> Logic
```

## Notes for Developers

- Treat the flow name, bean name, and logic name as part of the screen contract.
- If the bean shape changes, verify the JSP still reads the expected properties.
- If the logic class changes, confirm the XML wiring still resolves correctly.
- Because the surface area is small, renames can have outsized impact.
- When adding new flows, follow the same bean + logic + XML + JSP pattern so the package stays consistent with the rest of the web layer.

## Summary

`Eo` is a small web integration area whose documented responsibilities center on a named screen flow. Its child module, `web`, and the nested `webview` flow show a pattern where a bean and a logic class cooperate to support a JSP-driven screen, with XML providing the runtime wiring. The overall architecture appears intentionally lightweight: this package supplies stable Java entry points while the broader web framework and templates do most of the orchestration.