# Eo / Web

## Overview

`eo.web` appears to be the web-facing portion of the Eo codebase, but the indexed evidence for this package is very small. At the package level there are no captured source files, classes, or direct dependencies, so the best-supported conclusion is that this area acts primarily as a container for web presentation modules rather than a place where shared business logic lives.

The documented child module, `eo.web.webview`, shows the shape of that presentation layer: a screen-oriented module that is assembled through framework configuration, a small state bean, a lifecycle logic class, and a JSP view. In other words, this package appears to exist to support web UI composition and routing more than domain computation.

## Sub-module Guide

### `webview`

The only documented child page under `eo.web` is `webview`, which in turn documents the `ACA001SF` screen flow.

`ACA001SF` is structured as a coordinated set of view-layer pieces:

- `ACA001SFBean` carries the screen state, but it is intentionally minimal and only exposes a single `value` property.
- `ACA001SFLogic` provides the execution hook for the screen lifecycle, though the documented implementation is empty.
- XML resources wire the bean and logic into the application runtime.
- A JSP consumes the bean and renders the final screen.

The relationship among those parts is important. The bean does not seem to be useful on its own; it becomes meaningful only when configuration exposes it to the view. Likewise, the logic class does not appear to implement business rules; it appears to satisfy the framework contract that drives the screen lifecycle. The result is a configuration-led web screen where the Java types and the view template are tightly coupled through XML.

Because `webview` is the only child module documented here, it likely represents the main pattern used by `eo.web`: define a small screen unit, bind it through configuration, and render it through a JSP-based view layer.

## Key Patterns and Architecture

### Configuration-first web assembly

The evidence suggests that this area relies on XML to connect the moving parts of a page or screen. The runtime shape is defined less by imperative code and more by how the framework resolves bean, logic, and view references.

### Thin presentation model

The documented bean is intentionally small, which suggests the module is designed around a narrow view contract. That makes sense in a screen-oriented package where the UI only needs a limited amount of state.

### Lifecycle hook over business service

`ACA001SFLogic` looks like a framework callback point rather than a service class. The empty execute method implies that the module is demonstrating or exercising the screen lifecycle, not implementing complex behavior.

### Data flow across the screen stack

A simple flow emerges from the child documentation:

1. XML creates the runtime linkage.
2. The logic class participates in the screen lifecycle.
3. The bean carries values into the view.
4. The JSP renders the final output.

### Mermaid diagram

```mermaid
flowchart TD
  EoWeb["eo.web"] --> 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 in the index for `eo.web`, so integration details have to be inferred from the child module documentation.

### Observed integration points

The `webview` child page references the following resources:

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

These references suggest that `eo.web` integrates with a larger web application stack built around configuration files and view templates. The package appears to sit at the boundary between framework wiring and presentation rendering, with Faces-style configuration or similar mechanisms exposing data to the JSP layer.

## Notes for Developers

- Treat this area as presentation infrastructure. The important behavior appears to be in the wiring, not in the method bodies.
- Changes to `ACA001SFBean` may affect XML and JSP references even if the Java change looks small.
- `ACA001SFLogic` appears to be a lifecycle contract, so keep its signature and naming stable if other configuration files refer to it.
- The absence of indexed source at the package level means documentation and configuration are especially important here; small refactors could break the screen chain even when the Java code looks trivial.
- When extending `eo.web`, preserve the existing configuration-driven style unless there is a clear reason to introduce richer server-side behavior.

## Reference Links

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