# Eo

## Overview

`Eo` appears to be a small web-facing area of the codebase that provides the Java-side wiring for screen flows rather than a large domain or service layer. Based on the child documentation, its main purpose is to connect configuration, JSP rendering, and framework lifecycle hooks for specific pages.

In other words, this area seems to exist so that a page can be declared in XML, rendered in JSP, and backed by a minimal Java bean plus a logic class. The Java code is intentionally thin: it supports the screen contract while the actual orchestration appears to live in the surrounding web framework and view descriptors.

## Sub-module Guide

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

`eo.web` is the only documented sub-module under `Eo`, and it is the integration point for page-oriented web behavior. The child documentation describes it as a web-facing area that binds configuration-driven screen definitions to Java types used by the UI layer.

Inside that area, the documented `webview` slice shows a very compact pairing:

- `ACA001SFBean` carries view state through a minimal `String` property named `value`.
- `ACA001SFLogic` provides the execution hook for the screen lifecycle, although its `execute()` method is currently empty.

The relationship between these pieces is one of responsibility separation rather than collaboration. The bean represents state for the view, while the logic class represents the framework callback for processing. The XML and JSP artifacts coordinate both, so the Java classes do not appear to directly manage each other or own the full request flow.

This means `eo.web` should be read as a screen adapter layer. It supplies the smallest possible Java surface needed for the framework to bind a page, render it, and invoke lifecycle logic when needed.

## Key Patterns and Architecture

The architecture across the documented area appears to be page-centric and configuration-driven:

- **Configuration-driven binding** - XML descriptors and JSP pages reference the Java types directly.
- **State carrier pattern** - the bean exists primarily to expose view data.
- **Lifecycle hook pattern** - the logic class provides the execution entry point for the screen.
- **Thin adapter layer** - the module does not appear to contain heavy business logic; it adapts the page to framework expectations.

A likely flow through the system is:

1. The XML descriptor defines how the screen is wired.
2. The framework resolves the bean and logic classes.
3. The JSP renders using the bean state.
4. The logic class participates in the screen lifecycle when invoked by the framework.

### Interaction diagram

```mermaid
flowchart TD
  Xml["WEBGAMEN_FULL_ACA001.xml"] --> Bean["ACA001SFBean"]
  Xml --> Logic["ACA001SFLogic"]
  Jsp["FULL_ACA001010PJP.jsp"] --> Bean
  Jsp --> Logic
  Bean --> ViewState["View data"]
  Logic --> Lifecycle["Screen lifecycle"]
```

This diagram shows that the module’s center of gravity is the wiring between configuration, rendering, and execution rather than direct Java-to-Java collaboration.

## Dependencies and Integration

The provided evidence does not show resolved package dependencies or source-level dependencies for `Eo`, so integration seems to happen primarily through external web artifacts instead of internal module coupling.

The important integration points called out in the child documentation are the page-level references:

- [WEBGAMEN_FULL_ACA001.xml](.codewiki/eo/web/webview/ACA001SF.md)
- [FULL_ACA001010PJP.jsp](.codewiki/eo/web/webview/ACA001SF.md)

These references suggest that `Eo` sits at the presentation boundary of the system. It appears to connect into the wider application through page descriptors and JSPs, while the Java classes supply the state and lifecycle contract those files expect.

## Notes for Developers

- The documentation footprint is very small, so `eo.web` is the main source for understanding this area.
- `ACA001SFLogic.execute()` is currently a no-op, which suggests this may be scaffolding for future page behavior rather than a fully implemented flow.
- `ACA001SFBean` exposes only a `value` property, so the current model is deliberately narrow and view-focused.
- Because the wiring appears to be configuration-based, changes to Java class names or properties likely require matching XML and JSP updates.
- When modifying this area, trace the page descriptors first; the behavior appears to be defined more by integration contracts than by internal code paths.