# Eo / Web

## Overview

`eo.web` appears to be the web-facing layer of the `Eo` application. Based on the available child documentation, its role is not to hold deep business logic, but to provide the structure that lets web pages, configuration files, and framework entry points work together.

The documented child area, `eo.web.webview`, suggests that this package acts as a boundary between configuration-driven page flow and the runtime objects that support it. In other words, `eo.web` seems to be where web presentation concerns are assembled, with page state and execution hooks exposed in the form that the surrounding framework expects.

## Sub-module Guide

### `eo.web.webview`

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

`eo.web.webview` appears to be the main web-view integration layer under this package. The child documentation describes it as a thin adapter that connects view state and page execution into the larger web framework.

The core example is `ACA001SF`, which contains two cooperating pieces:

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

These two parts work together as a split responsibility model: the bean carries data that the page can render, while the logic class gives the framework a place to begin processing. The child page also notes that `ACA001SFLogic` appears in multiple source variants, which suggests this area may be used both for application wiring and for configuration-resolution fixtures.

Taken together, `eo.web.webview` seems to represent the part of the system where the web layer resolves a page definition into executable logic and view state. It is not described as a feature-rich domain module; instead, it looks like connective tissue that binds XML/JSP configuration to the framework lifecycle.

## Key Patterns and Architecture

### Thin web adapter

The available documentation points to a deliberately small surface area. The package appears to expose just enough structure for the web framework to find:

- a bean for page data
- a logic class for execution
- an `execute()` method that matches the expected contract

This suggests a classic adapter pattern: the package translates between external configuration and the framework's page execution model.

### Configuration-driven page assembly

The child module appears to be wired mostly through XML and JSP references rather than through explicit code dependencies. That means the important contracts are structural:

- package names must remain stable
- class names must remain discoverable
- method signatures, especially `execute()`, matter to the runtime

This appears to make the package sensitive to refactoring in a way that code-only modules are not. Renames or moves likely need coordinated updates in configuration files.

### Data and execution are separated

The child documentation shows a clean split between state and behavior:

- the bean stores the values the view needs
- the logic class owns the lifecycle entry point

That separation makes the system easier to reason about at the web boundary, because the framework can populate or read state independently from the logic that starts page processing.

### Interaction diagram

```mermaid
flowchart LR
ConfigFiles["XML and JSP configuration"] --> 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 evidence available for `eo.web` itself does not show indexed source files, package dependencies, or captured class symbols. That means the module-level view has to be inferred from the child documentation and from how the child is referenced externally.

From the child page, `ACA001SF` is connected to several configuration and view 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.web` integrates with the rest of the application primarily through external configuration rather than direct package-to-package code calls. The module likely sits at the point where web page definitions, backing objects, and framework callbacks are assembled into a working page flow.

### Integration implications

- Changes to class names or package paths may require configuration updates in XML and JSP files.
- The bean is part of the view contract, while the logic class is part of the execution contract.
- The package may be used as a fixture for testing how the framework resolves web-view classes from configuration.

## Notes for Developers

- Treat `eo.web` as a web boundary layer, not as a domain service package.
- Check XML and JSP references when changing anything in `eo.web.webview`, because those appear to be the primary integration points.
- Preserve the expected `execute()` entry point unless the surrounding framework contract is changing as well.
- If you introduce new view state, confirm how the bean is populated and whether the framework expects setters or direct field access.
- The index does not show strong source-level coupling here, so the safest assumption is that wiring happens outside the Java code itself.

## Summary

`eo.web` appears to provide the structural layer that lets the Eo application present web pages through configuration-driven wiring. Its documented child, `eo.web.webview`, shows the pattern clearly: a small bean carries page data, a logic class provides the execution hook, and XML/JSP resources connect them to the broader web framework.