# Eo / Web

## Overview

The `eo.web` package sits near the root of the `eo` domain hierarchy and serves as the **web-facing surface area** for the application. It houses the infrastructure and page-level components that handle HTTP requests, render user interfaces, and coordinate the MVC (Model-View-Controller) flow for web pages.

At this point, the primary content under `eo.web` is the `webview` sub-package, which implements Struts-style MVC components for specific web pages. The broader `eo.web` package appears to act as a namespace bucket that will contain additional web-facing groups (such as APIs, static resources, or other view subsystems) as the application grows.

The module-level index reports zero indexed source files and zero classes, which likely means the indexing scope did not cover this package. The content described below is synthesized from the child module documentation.

## Sub-module Guide

### Webview — Page-Level MVC Stacks

**Source code:** [`eo.web.webview`](full-fixture-codebase/src/java/eo/web/webview/)

The `webview` sub-package is the only documented child of `eo.web`. It organizes each web page as a self-contained module under a flat sub-package hierarchy. Every page module includes four tightly coupled files:

| Artifact | Role |
|---|---|
| `*Bean.java` | JavaBean view-model that exposes properties the JSP reads |
| `*Logic.java` | Controller class that handles the request, performs logic, and populates the bean |
| `*xml` (e.g., `WEBGAMEN_FULL_ACA001.xml`) | Struts XML config mapping an action name to the `*Logic` class |
| `*.jsp` | JSP template that renders the page using bean properties |

Currently, the only fully documented page module is **`ACA001SF`**, which scaffolds a "Futurity" branded view. The naming convention (`ACA001SF` -> `ACA001SFBean`, `ACA001SFLogic`, `WEBGAMEN_FULL_ACA001.xml`, `FULL_ACA001010PJP.jsp`) makes it straightforward to locate all four files for any given page by searching for the `ACA001SF` prefix.

The relationship between `eo.web` and `webview` is therefore one of **namespace containment**: `eo.web` is the parent package declaration, and `webview` is its first (and so far only) functional child that brings real MVC components into existence. As more page modules are added, they would follow the same flat-under-webview pattern rather than nesting deeper.

## Key Patterns and Architecture

### Struts 1.x MVC Convention

All known webview modules follow the classic Apache Struts 1.x MVC pattern:

```mermaid
flowchart TD
    User["Browser / User"] -->|HTTP Request| Dispatcher["Struts XML Config"]
    Dispatcher -->|Route| Logic["*Logic.execute()"]
    Logic -->|Populates| Bean["*Bean"]
    Bean -->|Data| JSP["JSP Template"]
    JSP -->|HTML| User
```

1. **Routing** -- The Struts XML config file acts as a central dispatcher, mapping an action name (e.g., `ACA001SF`) to the corresponding `*Logic` class.
2. **Logic** -- The `*Logic` class implements the controller role. In the standard pattern, `execute()` performs business logic, queries data, and populates the bean before forwarding.
3. **Bean** -- The `*Bean` class is a plain JavaBean (POJO) exposing properties via `getXxx()`/`setXxx()` methods. The JSP reads these properties using JSTL/EL syntax.
4. **View** -- The `.jsp` file renders the final HTML response by iterating over bean properties.

### Stub Implementation Pattern

A notable characteristic of all known classes under `eo.web` is that they are **skeletal**. The `ACA001SFLogic.execute()` method has an empty body, and `ACA001SFBean` exposes only a getter for its `value` property with no setter. This suggests one or more of the following:

- The pages are served with static content and the backend logic is added incrementally.
- The bean values are injected through a mechanism outside the logic class (e.g., a framework interceptor, servlet filter, or decorator pattern).
- This is early scaffolding awaiting feature implementation.

### Write-Once Bean Discipline

The `ACA001SFBean` class defines only a getter (`getValue()`) and no setter. In standard Struts usage, form beans are bidirectional (framework populates from request params via setters, then the JSP reads via getters). The absence of a setter implies these beans are **output-only models** -- data flows from the logic layer into the bean once, and the JSP consumes it. This is a design choice that enforces immutability after the logic phase and prevents the JSP from accidentally triggering unwanted side-effects through property setters.

### Flat Hierarchy Design

The `webview` package uses a **flat** sub-package structure -- each page module lives one level deep under `webview`, with no further nesting. This keeps the package depth shallow, makes grep searches for a page's files straightforward, and avoids the "deep package hell" problem that can emerge in large Struts applications.

## Dependencies and Integration

### Inbound Dependencies

| Consumer | Relationship |
|---|---|
| Struts XML config files | Map action names to `*Logic` classes |
| JSP pages | Read from `*Bean` properties for rendering |

### Outbound Dependencies

The known classes (`ACA001SFBean`, `ACA001SFLogic`) have **no Java-level imports** beyond the standard `java.lang` library. This is consistent with their minimal, stub-level nature. When features are added, they will likely pull in:

- Struts framework classes (`org.apache.struts.action.Action`, `ActionForm`, etc.)
- Domain model or persistence packages for business logic
- Utility libraries (e.g., Apache Commons, logging frameworks)

### Position in the Broader `eo` System

```mermaid
flowchart TD
    subgraph eo["eo (root domain)"]
        subgraph eo_web["eo.web"]
            subgraph webview["eo.web.webview"]
                sub1["Page module 1<br/>(e.g., ACA001SF)"]
                sub2["Page module 2<br/>(future)"]
            end
        end
    end
    webview -->|"MVC stack"| XML["Struts XML Config"]
    XML -->|"Routes to"| Logic["*Logic"]
    Logic -->|"Populates"| Bean["*Bean"]
    Bean -->|"Data for"| JSP["JSP"]
    JSP -->|"HTML response"| Browser["Browser"]
```

`eo.web` is a direct sub-package of the root `eo` domain. The `web` package is the **web-facing layer**, while deeper modules (`webview`) handle specific page implementations. Future expansion may add sibling packages under `eo.web` for REST APIs, file serving, or other web-oriented concerns.

## Notes for Developers

- **Expect stubs.** All known classes are skeletal with empty method bodies. Verify whether real logic should already exist before building on top of these scaffolds.
- **Struts convention is key.** The naming (`*Logic`, `*Bean`, `execute()`) strongly signals Struts 1.x. If the project has migrated from Struts or uses a different action framework, cross-reference the XML config to confirm the routing layer is current.
- **"Futurity" as a domain label.** `ACA001SFLogic` carries a Javadoc comment referencing "Futurity." This may indicate a client-branded feature or sub-project. If additional `*SF` modules appear, they may share a domain model worth understanding collectively.
- **Bean asymmetry.** Several beans expose getters without setters. If you need to modify a bean's value from your own code, you must add a setter explicitly.
- **Indexing gap.** The code index reports zero source files and zero classes for this module. If this is an oversight, consider expanding the indexing scope to include `eo.web`. If the index is authoritative, some files may have been removed or relocated.
- **Add pages flat.** New page modules should be added as a flat sub-package directly under `eo.web.webview` (e.g., `eo.web.webview.NEXTSF`), containing the four standard files: `*Bean.java`, `*Logic.java`, XML config, and JSP.