# Eo / Web

## Overview

`eo.web` appears to be the web-facing portion of the Eo codebase, with its documented surface centered on webview wiring rather than on shared business services or reusable framework infrastructure. Based on the available child documentation, this package is responsible for connecting Java-side view logic to configuration and presentation artifacts so that specific screens can be activated and rendered by the broader application.

The evidence suggests a deliberately small and integration-oriented module. Rather than defining a deep hierarchy of controllers, services, and helpers, `eo.web` seems to provide a stable naming and binding layer for individual web flows. In practice, that makes the package an entry point for UI behavior that is mostly orchestrated by external XML and JSP files.

## Sub-module Guide

### `webview`

[`webview`](.codewiki/eo/web/webview.md) is the only documented child area under `eo.web`. It represents a focused webview subsystem with one named flow, `ACA001SF`.

The child documentation describes `ACA001SF` as a paired unit made up of:

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

The relationship between these pieces is important: the bean carries the data the view needs, while the logic class provides the action hook that the framework calls when the flow is triggered. This appears to be a thin-view pattern where the child module does not own much computation itself, but instead provides the Java-side contract that external configuration and templates depend on.

The child page also shows that the flow is referenced by:

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

That means `webview` is best understood as the coordination layer for a specific view path: XML activates the flow, Java supplies the bean and logic, and JSP renders the result. The sub-module is therefore less a library and more a named integration endpoint.

## Key Patterns and Architecture

### Flow-oriented web integration

Across the documented material, `eo.web` appears to follow 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 that the presentation layer needs.
4. A JSP renders the UI based on that state.

This suggests that the package is built around predictable wiring conventions rather than heavyweight in-module orchestration. The important design decision is not complex algorithmic processing, but stable alignment between Java types, XML configuration, and JSP views.

### Bean and logic pairing

The child module shows a classic separation of concerns between state and behavior. The bean and logic class are paired so that:

- state remains explicit and easy for the view layer to consume
- behavior remains centered in a named framework entry point

This pattern makes each flow easy to extend without forcing the presentation model and execution path into the same class. It also helps keep screen-specific code isolated from broader application concerns.

### Minimal surface area, high naming sensitivity

No source files, package dependencies, or cross-module relationships were indexed directly for `eo.web`. That means the documented architecture is intentionally sparse in the code index, but the references to XML and JSP imply that the runtime behavior depends heavily on exact names and conventions.

For developers, that usually means small renames can have large effects. The package likely behaves as a contract boundary where the Java classes, configuration, and templates must stay synchronized.

## Dependencies and Integration

### External integration points

The documented child flow integrates with two external artifacts:

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

Those references place `eo.web` at the edge between framework configuration and user-facing presentation. The XML appears to bind the flow into the application runtime, while the JSP consumes the bean and potentially the logic contract for rendering.

### What is not visible in the index

The available evidence does not show resolved package dependencies, indexed source files, or deeper child modules for `eo.web`. As a result, the module should be treated as a thin integration surface rather than a broadly reusable subsystem.

### How this area fits the wider system

This appears to be one of the system's web entry points: a place where the application exposes a screen or screen flow through framework-driven wiring. The main value of the package is therefore compatibility with the surrounding web stack, not internal reuse across many business domains.

## Mermaid Diagram

```mermaid
flowchart TD
Parent["eo.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 Java class names and flow names as part of the public contract for the screen wiring.
- If you change the bean shape, check the consuming JSP to keep the presentation contract aligned.
- If you change the logic entry point, verify the XML wiring still resolves correctly.
- Because the package surface is small, it is easy to underestimate the impact of a rename or signature change.
- When adding new flows, follow the same pattern of bean + logic + external wiring so the module remains consistent with the rest of the web layer.

## Summary

`eo.web` is a small web integration area whose documented responsibilities center on named view flows. Its child module, `webview`, shows a pattern where a bean and a logic class cooperate to support a specific 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.