# Eo

## Overview

`eo` appears to be a parent namespace for the application’s web-facing screen modules. The available evidence for the package itself is sparse: no source files, classes, interfaces, methods, or package-level dependencies were indexed directly under `eo`. That means the best-supported view of this area comes from its child documentation, especially `eo.web`, which shows that this subtree is organized around configuration-driven UI composition rather than shared domain logic.

At a high level, `eo` seems to serve as a container for presentation-oriented modules that assemble screen state, lifecycle hooks, and view templates into runnable web pages. The emphasis is on wiring and structure, not on heavy computation.

## Sub-module Guide

### `eo.web`

The documented child page for this parent is `eo.web` at [web.md](.codewiki/eo/web.md). That page describes the web-facing portion of the codebase and shows a consistent pattern: a screen unit is built from a bean, a logic class, XML configuration, and a JSP view.

Within `eo.web`, the only explicitly documented screen flow is `webview`, centered on `ACA001SF`:

- `ACA001SFBean` holds the minimal screen state.
- `ACA001SFLogic` acts as the lifecycle hook for the screen.
- XML resources bind the bean and logic into the runtime.
- A JSP renders the final output.

The relationship between these parts matters more than any one class by itself. The bean is not meaningful in isolation; it becomes useful when the configuration exposes it to the view. The logic class also appears to be framework-facing rather than business-facing, suggesting it exists mainly to satisfy the screen lifecycle contract. Taken together, this makes `eo.web` look like a presentation layer built from small, declarative screen units.

### How the child module relates to `eo`

`eo` is best understood as the umbrella namespace for this style of web composition. `eo.web` provides the first level of specialization, and the `webview` documentation shows the concrete implementation pattern underneath it. In that sense, `eo` defines the area of the system, while `eo.web` defines how that area is assembled into UI screens.

## Key Patterns and Architecture

### Configuration-led screen assembly

The strongest architectural signal in this subtree is configuration-first composition. XML appears to connect the bean, logic, and JSP pieces into a screen flow, so runtime behavior is defined as much by metadata as by code.

### Thin presentation model

The documented screen bean is intentionally small. That suggests the module is designed around narrowly scoped view state, which keeps screen contracts simple and easy to bind into the view layer.

### Lifecycle hook over business service

The logic class appears to be a framework callback point rather than a service with domain responsibility. This implies that `eo` is primarily about screen orchestration and rendering, not standalone business processing.

### Data flow across the screen stack

A simple flow emerges from the child documentation:

1. XML establishes the runtime wiring.
2. The logic class participates in the screen lifecycle.
3. The bean carries values into the view.
4. The JSP renders the final page.

### Mermaid diagram

```mermaid
flowchart TD
  Eo["eo"] --> EoWeb["eo.web"]
  EoWeb --> Webview["eo.web.webview"]
  Webview --> ACA001SF["ACA001SF"]
  ACA001SF --> Bean["ACA001SFBean"]
  ACA001SF --> Logic["ACA001SFLogic"]
  ACA001SF --> XML["XML configuration"]
  ACA001SF --> JSP["JSP view"]
  XML --> Logic
  XML --> Bean
  Logic --> JSP
  Bean --> JSP
```

## Dependencies and Integration

No package-level dependencies were resolved directly for `eo`, so integration details must be inferred from the child documentation and exact code links present there.

### External or framework-facing integration points

The `eo.web` documentation references the following resources:

- `WEBGAMEN_FULL_ACA001.xml`
- `WEBGAMEN_ACA001010PJP.xml`
- `x33S_ACA001.xml`
- `faces-config.xml`
- `FULL_ACA001010PJP.jsp`
- `external-refs.xml`

These names suggest that `eo` participates in a larger web application stack where framework configuration exposes screen state and lifecycle objects to a JSP-based rendering layer. The package appears to sit at the boundary between application wiring and UI presentation.

### System integration model

This appears to be a modular presentation subsystem rather than a self-contained service layer. The main integration mechanism is not direct dependency injection code visible in the index, but configuration files that connect the runtime pieces into a page flow.

## Notes for Developers

- Treat `eo` as presentation infrastructure unless later documentation shows deeper domain responsibilities.
- Small changes to beans or logic classes may have outsized impact because configuration and JSP references likely depend on exact names.
- Preserve the configuration-driven style when extending this area; the documented pattern suggests that the system expects screens to be assembled declaratively.
- Because the package-level index is sparse, child wiki pages are the best source of truth. In practice, changes here should be reviewed against XML and JSP wiring, not just Java signatures.
- If you add new screen flows under `eo.web`, follow the same bean-logic-configuration-view structure so the module remains consistent and easy to reason about.

## Reference Links

- [web.md](.codewiki/eo/web.md)