# Eo / Web

## Overview

The `eo.web` module is the web-facing root package of the application. It serves as the structural anchor for all web views — screens that users interact with through a browser. It follows a traditional server-side MVC pattern (resembling Struts 1.x), where each screen is assembled from a consistent trio of components: a **bean** (data carrier), a **logic class** (action-style controller), and an **XML config + JSP view** pair (routing and rendering).

At present, `eo.web` is a parent package with no directly indexed Java source files of its own. Its substance comes from its child subpackage `eo.web.webview`, which contains the first screen implementation (`ACA001SF`). The module as a whole is currently scaffolding — the patterns and structures are in place so that new web screens can be added by following the established template.

## Sub-module Guide

`eo.web` has one documented child subpackage:

### eo.web.webview

The `webview` subpackage contains the webview screen infrastructure. Its purpose is to provide a repeatable MVC pattern for building browser-facing screens. The sole implemented screen under `webview` is `ACA001SF`.

#### How `ACA001SF` fits in

`ACA001SF` is a self-contained stubbed screen. It does not depend on any other classes within `eo.web.webview`, and no other sub-modules currently exist in the index. It demonstrates the standard pattern that every future screen should follow:

| Component | Role |
|-----------|------|
| `ACA001SFBean` | Data carrier bean holding view-scoped state (currently one `String value` property) |
| `ACA001SFLogic` | Controller class with an `execute()` method stub |
| `WEBGAMEN_FULL_ACA001.xml` | XML action config that maps request paths to the bean and logic classes |
| `FULL_ACA001010PJP.jsp` | JSP view template that renders the page using bean properties via EL |

**Relationship to `eo.web`**: The parent package `eo.web` is the namespace umbrella. As new web screens are developed, they would be placed under `eo.web.webview` (or future sibling subpackages under `eo.web`) following the same three-component pattern that `ACA001SF` establishes.

## Key Patterns and Architecture

### MVC Trio Pattern

Every screen in this module follows a four-part structure:

```mermaid
flowchart TD
    REQ["Web Request"] --> M["eo.web
(parent package)"]
    M --> WV["eo.web.webview
(webview screens)"]
    WV --> AC["ACA001SF
(stubbed screen)"]
    AC --> AC_BEAN["ACA001SFBean
(data carrier)"]
    AC --> AC_LOGIC["ACA001SFLogic
(controller)"]
    AC --> AC_XML["WEBGAMEN config
(action mapping)"]
    AC --> AC_JSP["FULL_ACA001010PJP.jsp
(view template)"]
    AC_XML --> AC_BEAN
    AC_XML --> AC_LOGIC
    AC_JSP --> AC_BEAN
    FRM["Struts 1.x -style
MVC Framework"] --> M
```

The flow for any given screen is:

1. **XML Config** — Acts as the router. Maps a URL path to a bean class, a logic class, and a JSP view. This is likely Struts-style action configuration.
2. **Logic.execute()** — The action entry point. The framework instantiates the logic class and calls `execute()`, which is expected to populate the bean and return a result string (`"SUCCESS"`, `"FAILURE"`, etc.). Currently a no-op in `ACA001SF`.
3. **Bean** — A POJO holding view-scoped data. JSPs access bean properties via standard JavaBean getters, making them available in EL expressions (e.g., `${value}`).
4. **JSP View** — Renders the final HTML output, reading dynamic data from the bean.

### Design Observations

- **Thin scaffolding**: The `execute()` method is empty and the bean carries a single property. This is intentional — the structure exists as a template for future screens.
- **Bean convention**: New fields should follow standard JavaBean getter/setter naming so they are accessible in JSPs via EL.
- **Empty dependency footprint**: No external Java package dependencies are declared. This module relies on the broader application framework (likely Struts 1.x) for wiring and infrastructure.
- **Naming convention**: Screen names follow a pattern (`ACA` prefix + sequence number + type suffix like `SF`). This should be continued for new screens to maintain consistency.

## Dependencies and Integration

### Internal

No other submodules exist in `eo.web` at this time. `ACA001SF` stands alone within `eo.web.webview`.

### Inbound

| Dependency | Relationship |
|------------|-------------|
| `WEBGAMEN_FULL_ACA001.xml` | Wires `ACA001SFBean` and `ACA001SFLogic` together; defines the action mapping |
| `FULL_ACA001010PJP.jsp` | Consumes the bean for rendering; part of the presentation tier |

### Outbound

None declared. The Java classes themselves do not reference external packages.

### Framework Context

The architecture — XML-configured actions, `execute()` entry points, JSP views with Expression Language binding — strongly suggests a **Struts 1.x** or similar server-side MVC framework. The parent module connects to the broader application by being the top-level namespace for all web-facing screens. New screens added under `eo.web` (or its child `eo.web.webview`) will automatically participate in this routing and rendering pipeline.

## Notes for Developers

- **Before implementing logic**: Review surrounding modules for conventions on action structure, bean scoping, and result routing. The current implementation is a template, not a fully functional feature.
- **Adding a new screen**: Follow the `ACA001SF` pattern — create a bean with required fields (and getters/setters), create a logic class with an `execute()` method, wire them via XML config, and author the JSP.
- **Bean fields**: Always provide both `get` and `set` methods for new fields so they are accessible in JSP EL expressions.
- **Naming**: Use the existing convention (`ACA` + sequence number + type suffix) when naming new screens to maintain consistency with the broader application structure.
- **Framework specifics**: Consult the broader application architecture documentation for details on action mappings, scope management, and framework conventions (e.g., how `execute()` return values map to JSPs).