# Eo

## Overview

`Eo` appears to be a web-oriented area of the codebase whose main responsibility is to support configuration-driven page flow. Based on the available child documentation, this module does not expose a broad set of domain services or internal APIs; instead, it seems to provide the structural pieces that let the web framework resolve page state, execution entry points, and external configuration into a working page experience.

The clearest evidence is the `eo.web` subtree, which looks like the boundary where page definitions are assembled and handed off to the runtime. That suggests `Eo` is less about business rules and more about web integration, wiring, and page lifecycle support.

## Sub-module Guide

### `eo.web`

Source: [`.codewiki/eo/web.md`](.codewiki/eo/web.md)

`eo.web` is the only documented child area available for this package, and it appears to act as the web-facing layer for the overall `Eo` module. The child documentation describes it as the place where web presentation concerns are assembled rather than where deep business logic lives.

Within `eo.web`, the key documented sub-area is `eo.web.webview`, which appears to provide the actual bridge between framework callbacks and page state. The relationship is important: `eo.web` is the broader web boundary, while `eo.web.webview` is the concrete adapter-like layer that exposes the contracts the framework expects.

### `eo.web.webview`

Source: [`.codewiki/eo/web/webview.md`](.codewiki/eo/web/webview.md)

`eo.web.webview` appears to be the main integration point under `eo.web`. The child documentation describes a split-responsibility design centered on `ACA001SF`:

- `ACA001SFBean` holds minimal page state through a `value` property
- `ACA001SFLogic` provides the framework-facing `execute()` entry point

These pieces work together rather than independently. The bean represents the view data contract, while the logic class represents the execution contract. In practice, that means the framework can populate or read page data separately from the class that starts page processing.

The child page also notes that `ACA001SFLogic` appears in multiple source variants, which suggests this area may be used both as wiring for the application and as a fixture for configuration resolution or framework integration tests.

## Key Patterns and Architecture

### Boundary-layer design

`Eo` appears to follow a boundary-layer pattern: the package does not seem to own much business logic itself, but instead exposes the minimal structures needed for the web runtime to function. That makes the package more about integration than computation.

### Separation of data and execution

The child documentation shows a clear separation between:

- state held by `ACA001SFBean`
- lifecycle entry handled by `ACA001SFLogic.execute()`

This split keeps the view model and the execution hook distinct. It also makes the runtime contract easier to reason about, since the framework can treat page state and control flow as separate concerns.

### Configuration-driven wiring

The web area appears to rely on XML and JSP configuration rather than deep code-to-code coupling. The important contract points are therefore structural:

- package names must stay discoverable
- class names must remain stable
- the expected method signature, especially `execute()`, must remain available

This suggests that changes in `Eo` may require synchronized updates in configuration files, not just Java sources.

### Interaction diagram

```mermaid
flowchart LR
ConfigFiles["XML and JSP configuration"] --> WebModule["eo.web"]
WebModule --> WebView["eo.web.webview"]
WebView --> ACA001SFBean["ACA001SFBean"]
WebView --> ACA001SFLogic["ACA001SFLogic"]
ACA001SFLogic --> Execute["execute() entry point"]
ACA001SFBean --> PageState["Page state"]
Execute --> PageState
```

## Dependencies and Integration

The module-level evidence for `Eo` does not show indexed source files, package dependencies, or class-level symbols. As a result, the integration picture has to be inferred from the child documentation.

From the documented child page, `ACA001SF` is connected to several external resources, including:

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

This appears to indicate that `Eo` connects to the rest of the system primarily through web configuration rather than through direct package dependencies. The module likely sits at the point where page definitions, backing objects, and framework callbacks are assembled into a runnable page flow.

### Integration implications

- Renaming classes or moving packages may require coordinated XML and JSP updates.
- The bean seems to represent the view contract, while the logic class represents the execution contract.
- The package may be used as a framework-integration fixture, since the child documentation emphasizes configuration resolution and multiple source variants.

## Notes for Developers

- Treat `Eo` as a web boundary layer rather than a domain service package.
- Review XML and JSP references before changing anything under `eo.web.webview`, because those appear to be the main integration points.
- Preserve the expected `execute()` entry point unless the surrounding framework contract is changing as well.
- If you add or change page state, confirm how the bean is populated and whether the framework expects setters, getters, or direct field access.
- Because the index does not show strong source-level coupling here, configuration should be assumed to be the primary source of truth for wiring.

## Summary

`Eo` appears to provide the structural layer that lets the application present web pages through configuration-driven wiring. Its documented child area, `eo.web`, shows the pattern clearly: a web boundary organizes page state and runtime entry points, and `eo.web.webview` supplies the concrete bean-and-logic split that the framework can execute.