# Eo / Web

## Overview

`eo.web` appears to be the web-facing part of the Eo application, centered on screen wiring rather than business logic. Based on the available child documentation, this package is responsible for connecting framework configuration, executable screen logic, and view-layer bindings so that web pages can be rendered through the application's existing XML/JSP conventions.

The module does not show evidence of a broad internal API or a large number of collaborating classes. Instead, it seems to serve as a thin integration layer where names, beans, and logic entry points must line up with external configuration files. In that sense, `eo.web` is less about implementing behavior directly and more about making the web stack resolvable and consistent.

## Sub-module Guide

### `webview`

The only documented child module is `eo.web.webview`, which appears to hold the actual screen-level types for the web layer. Its child page describes a minimal pattern:

- `ACA001SFBean` provides a small presentation model with a `value` property.
- `ACA001SFLogic` provides an executable hook via `execute()`.

These are not independent features so much as two halves of a framework contract. The bean supplies data for rendering, while the logic class gives the framework something to invoke during page processing. The child documentation also notes that XML and JSP files outside the package bind these pieces together.

This relationship suggests that `webview` is the implementation surface for a screen or screen family, while the parent `eo.web` package provides the broader web-module context around it. In other words, the child module contains the concrete types that the rest of the web stack references by name.

### How the pieces relate

The system appears to follow a configuration-led flow:

1. External XML configuration selects a logic class by name.
2. The framework invokes `ACA001SFLogic.execute()`.
3. The logic and bean are paired with a JSP or similar view definition.
4. The view reads from `ACA001SFBean` to display screen data.

The child page also mentions a second `ACA001SFLogic` source-set variant under `xml-unresolved-fqn`, which suggests the package is used not only for runtime wiring but also for testing how fully qualified names resolve across source roots. That makes `webview` both a screen implementation area and a validation target for configuration resolution.

## Key Patterns and Architecture

A few architectural patterns span the web area:

- **Configuration-centered wiring** — the important relationships are defined outside the Java types, primarily in XML and JSP files.
- **Thin screen contracts** — the bean and logic classes are intentionally minimal so the framework can control most of the behavior.
- **Stable naming over rich APIs** — class names and method signatures matter more than internal complexity because the surrounding configuration depends on them.
- **Framework integration layer** — this package appears to mediate between the application framework and the view layer rather than implementing domain behavior itself.

### Interaction diagram

```mermaid
flowchart TD
    XmlConfig["XML configuration"] --> Logic["ACA001SFLogic"]
    Logic --> Execute["execute()"]
    Bean["ACA001SFBean"] --> JspView["JSP rendering"]
    XmlConfig --> Bean
    JspView --> XmlConfig
```

This diagram reflects the relationship described in the child documentation: configuration wires the logic class, the logic provides the execution entry point, and the bean supplies the data that the JSP consumes.

## Dependencies and Integration

The package-level code analysis for `eo.web` reports no indexed source files, no captured classes or interfaces, and no resolved package dependencies. So the integration story is inferred primarily from the child documentation rather than from direct source references.

The child page identifies several external files that participate in the web wiring:

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

These references imply that `eo.web` connects into multiple XML configuration paths and at least one JSP-based rendering path. The repeated appearance of the same screen names across these files suggests a shared naming convention and possibly a set of parallel configuration entry points for the same screen flow.

At the package level, the evidence does not show additional internal dependencies, so `eo.web` appears to rely more on the wider framework than on sibling Java packages.

## Notes for Developers

- This area appears to be highly sensitive to naming. If you change class names, method names, or property names, review every XML and JSP reference first.
- `ACA001SFBean` currently exposes only a single `value` property, so any expansion of the presentation model should be checked against the framework's binding rules.
- `ACA001SFLogic.execute()` is empty in the available documentation. Do not assume that business behavior belongs here without confirming the surrounding framework flow.
- The documented duplicate `ACA001SFLogic` in another source set suggests this package may participate in configuration-resolution tests as well as runtime page wiring.
- Because the module is configuration-driven, small Java changes can have large effects on view resolution and page startup.
- When working in this area, treat XML, JSP, and Java as one integrated unit rather than as separate concerns.