# Eo

## Overview

The `eo` package serves as the root domain namespace for the application. It provides the top-level packaging layer under which all functional sub-packages are organized. At this stage, `eo` acts as a domain umbrella — the primary documented content resides in its `web` sub-package (`eo.web`), which itself delegates page-level MVC components to the `webview` sub-package.

This appears to be an early-stage codebase. The code index reports zero source files, classes, and methods for the `eo` module, which suggests either a gap in indexing scope or that the application is in scaffolding mode where the structural skeleton is in place but functional implementations are still being added.

## Sub-module Guide

### eo.web — The Web-Facing Surface Area

**Source code:** `eo.web`

The `web` package is the first and currently primary child of `eo`. It represents the application's **web-facing layer** — the infrastructure and page-level components that handle HTTP requests, render user interfaces, and coordinate the MVC flow.

Within `eo.web`, the `webview` sub-package is the only documented child. 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 |

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 one of **namespace containment**: `eo.web` is the parent package declaration, and `webview` is its first functional child. 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 Response| 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 exposing properties via getter/setter 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` 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 (the 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 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` is the root domain package. Its primary documented child, `eo.web`, handles web-facing concerns, with `webview` providing the page-level MVC stacks. Future expansion under `eo.web` may add sibling packages 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 the `eo` module. If this is an oversight, consider expanding the indexing scope. 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.