# Eo / Web

## Overview

`eo.web` appears to be the web-facing package area for the Eo application. Based on the available child documentation, this package is responsible for screen-level presentation wiring rather than shared business logic. In other words, it seems to collect the pieces that let a request reach a screen action, carry state through a bean, and render a JSP view.

The package is currently very small in the index, so its role looks more like a thin integration boundary than a broad subsystem. The documented content suggests a framework-driven web layer where behavior is assembled through configuration and view binding.

## Sub-module Guide

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

`webview` is the only documented child area under `eo.web`. It appears to host a single screen implementation, `ACA001SF`, which is split into two cooperating parts:

- `ACA001SFBean` carries the screen data that the JSP renders.
- `ACA001SFLogic` provides the screen action entry point, likely invoked by the web framework.

The relationship between them is indirect but important: the logic class and bean are not simply helpers for each other, but separate roles in the same request flow. The bean represents state, while the logic class represents lifecycle or action handling. Their behavior is then tied together through external wiring in XML and JSP resources.

Because there are no other documented child modules, `webview` currently appears to be the main example of how this package is intended to be used: one screen module, one configuration set, one view.

## Key Patterns and Architecture

The structure here appears to follow a conventional screen-module pattern common in framework-based web applications:

1. A request is routed through XML configuration.
2. The framework invokes a logic class for screen execution.
3. The logic and its bean support the view model for the page.
4. The JSP renders the final screen using that state.

This arrangement keeps presentation state and execution flow separate. That separation is the main architectural idea visible from the documentation:

- **Bean** for renderable state
- **Logic** for screen entry and execution
- **XML** for request-to-screen wiring
- **JSP** for presentation

This appears to be a deliberately lightweight design. The parent package does not expose a shared service layer or cross-module orchestration; instead, the package is organized around individual screens and the artifacts that bind them into the web framework.

### Mermaid Diagram

```mermaid
flowchart TD
Web["eo.web"] --> Webview["webview"]
Webview --> ACA001SF["ACA001SF"]
ACA001SF --> ACA001SFBean["ACA001SFBean"]
ACA001SF --> ACA001SFLogic["ACA001SFLogic"]
ACA001SFBean --> JspView["FULL_ACA001010PJP.jsp"]
ACA001SFLogic --> JspView["FULL_ACA001010PJP.jsp"]
ACA001SFBean --> XmlConfig["WEBGAMEN_FULL_ACA001.xml"]
ACA001SFLogic --> XmlConfig["WEBGAMEN_FULL_ACA001.xml"]
```

## Dependencies and Integration

The evidence for `eo.web` itself does not show resolved package dependencies, source files, or cross-module relationships at the index level. That suggests the real integration points are external and expressed through framework resources rather than package imports.

From the child documentation, the most important integration artifacts are:

- [`WEBGAMEN_FULL_ACA001.xml`](.codewiki/eo/web/webview/WEBGAMEN_FULL_ACA001.xml) — the configuration that wires the screen into the web flow
- [`FULL_ACA001010PJP.jsp`](.codewiki/eo/web/webview/FULL_ACA001010PJP.jsp) — the JSP that renders the screen state

So `eo.web` seems to connect the application to the web framework by hosting screen-specific modules whose behavior is defined partly in code and partly in configuration.

## Notes for Developers

- This area appears to be screen-oriented rather than domain-oriented. When changing behavior, check the JSP and XML wiring as well as the Java classes.
- The documented surface is very narrow, so framework conventions likely matter more than local implementation details.
- `ACA001SFLogic.execute()` appears to be the primary execution hook for the screen, but the child documentation does not show substantial business logic yet.
- `ACA001SFBean` appears to be a simple view-state carrier, so any data source or initialization path may be outside the documented source.
- Because the package currently has only one documented child, additions here will likely establish the pattern for future web screens in this area.