# Eo / Web

## Overview

`eo.web` appears to be the web-facing integration area for the Eo codebase. Based on the available documentation, it is not a broad application framework or a deep domain layer; instead, it looks like a small set of screen-oriented wiring classes that connect configuration, JSP rendering, and lightweight Java execution hooks.

The main responsibility of this area seems to be supporting specific page flows through framework-driven view plumbing. In practice, that means the module provides the objects that a web screen needs to render and process, while the actual control flow is orchestrated externally by XML descriptors and JSP pages.

## Sub-module Guide

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

`eo.web.webview` is the documented child area under this package, and it provides the concrete implementation pieces for a screen flow centered on ACA001.

Its two visible types work together as a simple pair:

- `ACA001SFBean` holds view state, exposing a minimal `String` property named `value`.
- `ACA001SFLogic` acts as the execution hook for the screen lifecycle, although its `execute()` method is currently empty.

The relationship between them is deliberately lightweight. The bean is the data carrier that the page can read, while the logic class is the hook the framework can invoke during processing. This suggests a configuration-first design where the real wiring happens outside the Java classes themselves.

The child documentation also shows that these types are referenced by XML and JSP artifacts, which implies that `webview` is not an isolated business component. It is more of a screen adapter: it provides just enough Java structure for the web layer to bind a page to framework-managed state and execution.

## Key Patterns and Architecture

Across the documented sub-module, the architecture appears to follow a small, page-centric pattern:

- **Configuration-driven binding** - page descriptors and JSPs reference the Java types directly.
- **State carrier pattern** - the bean supplies a minimal model for the view layer.
- **Lifecycle hook pattern** - the logic class provides a framework entry point for page execution.
- **Thin Java layer** - the Java side does not appear to own the full workflow; it participates in a larger web framework contract.

A likely data flow is:

1. XML configuration declares the screen wiring.
2. The framework resolves the bean and logic classes.
3. The JSP reads the bean while rendering the page.
4. The logic class participates in the screen lifecycle when the framework invokes it.

### Interaction diagram

```mermaid
flowchart TD
  Xml["WEBGAMEN_FULL_ACA001.xml"] --> Bean["ACA001SFBean"]
  Xml --> Logic["ACA001SFLogic"]
  Jsp["FULL_ACA001010PJP.jsp"] --> Bean
  Jsp --> Logic
  Bean --> ViewState["View data"]
  Logic --> Lifecycle["Screen lifecycle"]
```

This diagram shows the key relationship in the area: configuration and view files coordinate the use of a small Java pair, rather than the Java classes calling each other directly.

## Dependencies and Integration

There are no resolved package dependencies or indexed source-level relationships for `eo.web` in the provided evidence. That absence is itself informative: the module seems to integrate primarily through external page wiring rather than through internal package dependencies.

The documented integration points are the child page's external references:

- [WEBGAMEN_FULL_ACA001.xml](.codewiki/eo/web/webview/ACA001SF.md)
- [FULL_ACA001010PJP.jsp](.codewiki/eo/web/webview/ACA001SF.md)

These references suggest that `eo.web` connects into the wider system at the presentation layer. The package likely sits between framework configuration and rendered UI, with the XML/JSP pair determining when and how the Java types are used.

## Notes for Developers

- The available documentation is very small, so `webview` is the primary source of truth for understanding this area.
- `ACA001SFLogic.execute()` is currently a no-op, so this area may be intentionally prepared for future page behavior rather than already implementing it.
- `ACA001SFBean` exposes only a getter for `value`, which implies a narrow, view-oriented model.
- Because the wiring appears to be configuration-based, renaming or reshaping the Java types likely requires matching updates in XML and JSP files.
- When extending this area, it is worth tracing the page descriptors first, since the control flow appears to be defined more by integration contracts than by direct Java code.