# Eo / Web

## Overview

`eo.web` appears to be the web-facing portion of the Eo codebase, but the available index for this parent package is sparse. There are no directly indexed source files, classes, or package dependencies at the parent level, so the clearest picture comes from the documented child area under `webview`. Taken together, the evidence suggests that this part of the system serves as a configuration-driven bridge between framework dispatch, view data objects, and JSP rendering.

In practical terms, `eo.web` seems to define the web boundary for one or more screens or actions. Rather than concentrating business logic in Java classes, it appears to rely on named beans and logic hooks that external XML and JSP resources bind to at runtime.

## Sub-module Guide

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

`webview` is the only documented child area for this parent package, and it provides the clearest evidence of how the web layer is organized.

From the child documentation, `webview` contains a very small but important contract:

- `ACA001SFLogic` acts as the execution-side entry point.
- `ACA001SFBean` acts as the view-side data carrier.
- XML configuration files wire those classes into the application flow.
- A JSP view reads the bean to render output.

The relationship between those pieces is more important than the individual classes themselves. `ACA001SFLogic` appears to be the runtime hook that the framework invokes, while `ACA001SFBean` appears to be the object handed to the presentation layer. The child module therefore behaves less like a general utility package and more like a screen-specific integration contract.

### How the child relates to the parent

Because `eo.web` has no other indexed children or source symbols in this analysis, `webview` effectively defines the observed behavior of the parent package. This appears to mean the parent package is a namespace for web integration concerns, while the child package contains the concrete screen wiring.

## Key Patterns and Architecture

### Configuration-driven wiring

The strongest architectural signal is that the system appears to be wired through XML and JSP references rather than through direct Java calls. The child documentation shows the same classes referenced from multiple external configuration files and one JSP, which suggests reflective or declarative instantiation by the web framework.

### Thin action layer, minimal state object

The `ACA001SFLogic.execute()` method is documented as empty, which implies the logic class may be a framework callback, placeholder, or compatibility stub rather than a business-service implementation. The bean is similarly minimal, exposing a single string value through a getter. That combination suggests the module is intentionally lightweight and likely exists to satisfy a framework contract.

### Data flow across the web boundary

A reasonable reading of the system is:

1. XML configuration selects the logic and bean classes.
2. The framework creates or resolves `ACA001SFLogic` at runtime.
3. The logic hook runs through `execute()`.
4. The bean is exposed to the view layer.
5. The JSP reads the bean value via `getValue()`.

This appears to make `eo.web` a bridge between dispatch, state exposure, and rendering.

```mermaid
flowchart TD
Config["XML configuration"] --> Logic["ACA001SFLogic"]
Config --> Bean["ACA001SFBean"]
Logic --> Execute["execute()"]
Bean --> Value["getValue()"]
Jsp["JSP view"] --> Bean
```

## Dependencies and Integration

The parent package analysis did not resolve direct package dependencies, and no source-level imports were indexed for `eo.web` itself. The integration picture therefore comes from the child documentation and its referenced external files.

### Referenced integration points from the child module

The following external resources appear to consume the `webview` classes:

- `WEBGAMEN_FULL_ACA001.xml` uses `ACA001SFBean` and `ACA001SFLogic`
- `faces-config.xml` uses `ACA001SFBean`
- `WEBGAMEN_ACA001010PJP.xml` uses `ACA001SFBean` and `ACA001SFLogic`
- `x33S_ACA001.xml` uses `ACA001SFBean` and `ACA001SFLogic`
- `FULL_ACA001010PJP.jsp` uses `ACA001SFBean`
- `external-refs.xml` uses `ACA001SFLogic`

### What this implies for the larger system

- The web layer appears to be heavily configuration-driven.
- Class names and package names are likely part of the public contract.
- Changes in this package may break XML wiring or JSP references even when Java compilation still succeeds.
- The lack of indexed dependencies at the parent level suggests the framework integration may live mostly in external resources rather than in explicit source imports.

## Notes for Developers

- Treat the classes under `webview` as integration contracts, not just implementation details.
- If you rename classes, move packages, or change public method signatures, verify every XML and JSP reference that mentions them.
- The empty `execute()` method suggests behavior may be intentionally delegated elsewhere. Before adding logic, confirm whether the surrounding framework expects the class to remain minimal.
- `ACA001SFBean` is documented as read-only in the child page. If the framework populates it reflectively, adding setters or changing the field shape could alter binding behavior.
- Because the parent package has no other indexed children, future additions should preserve the same configuration-first style unless the web architecture is being intentionally redesigned.

## Relationship Summary

- `eo.web` is the parent web integration boundary.
- `webview` contains the concrete, screen-level wiring observed in the analysis.
- `ACA001SFLogic` provides the runtime entry point.
- `ACA001SFBean` carries data into the view layer.
- XML resources connect the runtime hook and bean to the application.
- JSP views consume the bean to render the response.

Overall, `eo.web` appears to be a small but important web layer whose main job is to keep framework-driven screens consistently wired between configuration, execution, and presentation.