# Eo

## Overview

The `eo` module is the top-level web-facing root package of the application. It serves as the structural namespace for all browser-visible screens and user-facing views. At present, `eo` is primarily an organizational scaffold — its sole purpose is to provide a consistent parent package (`eo.web`) under which individual web screens are developed. The actual implementation substance lives in its child subpackage `eo.web.webview`, which currently contains one stubbed screen (`ACA001SF`).

The module follows a traditional server-side MVC pattern (resembling Struts 1.x), where each screen is assembled from a consistent set of components: a data bean, a controller-like logic class, an XML action mapping config, and a JSP view. New screens are expected to be added under `eo.web` (or its future sibling subpackages) by following the established template.

## Sub-module Guide

`eo` has one child subpackage:

### eo.web

`eo.web` is the direct child of `eo` and acts as the web-facing root. It contains no directly implemented Java classes itself — instead, it serves as a namespace umbrella for its subpackages. Its substance comes from the `webview` subpackage.

### eo.web.webview

`eo.web.webview` is the first (and currently only) webview screen implementation within the `eo` module. It provides a repeatable MVC pattern for building browser-facing screens. The sole implemented screen is `ACA001SF`, which demonstrates the four-component pattern every future screen should follow:

| Component | Role |
|-----------|------|
| `ACA001SFBean` | Data carrier bean holding view-scoped state |
| `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 |

**How they relate**: `eo` is the top-level root package, `eo.web` is its direct child that groups all web screens, and `eo.web.webview` is where the first screen implementation lives. As new screens are developed, they will follow the same nesting pattern — added under `eo.web.webview` or alongside it as sibling subpackages under `eo.web`.

## Key Patterns and Architecture

### MVC Trio Pattern

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

```mermaid
flowchart LR
    EO["eo
(root package)"] --> WEB["eo.web
(web-facing screens)"]
    WEB --> WV["eo.web.webview
(webview screens)"]
    WV --> ACA["ACA001SF
(stubbed screen)"]
    ACA --> BEAN["ACA001SFBean
(data carrier)"]
    ACA --> LOGIC["ACA001SFLogic
(controller)"]
    ACA --> CONFIG["XML action config
(action mapping)"]
    ACA --> VIEW["JSP view
(rendering)"]
    CONFIG --> BEAN
    CONFIG --> LOGIC
    VIEW --> BEAN
    FRAM["Struts 1.x -style
MVC Framework"] --> WEB
```

The request flow for any given screen:

1. **XML Config** — Acts as the router, mapping a URL path to a bean class, a logic class, and a JSP view. This is 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.
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 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 subpackages exist in `eo` at this time. `ACA001SF` stands alone within `eo.web.webview`. The entire module is currently a single-screen scaffold waiting for additional implementations.

### 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 `eo` module connects to the broader application by serving as 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).