# Eo / Web / Webview

## Overview

The `eo.web.webview` package forms the web presentation layer of the Futurity application. It provides the view-side of an MVC (Model-View-Controller) architecture, built on a Java server-side framework (likely Apache Struts) with JSP-based views. This layer is responsible for rendering UI to end users — routing incoming HTTP requests through action logic classes, preparing data beans, and forwarding to JSP templates for HTML rendering.

At present, the package appears to be in a skeleton or scaffold state. The only implemented sub-module, `ACA001SF`, contains placeholder classes with no active business logic. This suggests the module is either a foundational fixture within the application, a template for new feature modules, or an area still under development.

## Sub-module Guide

The webview package contains a single sub-module:

### ACA001SF

The `ACA001SF` sub-package is a minimal view module that establishes the structural pattern for all webview modules in this package. It demonstrates the standard MVC flow:

1. **Request routing** via XML configuration (`WEBGAMEN_FULL_ACA001.xml`) maps HTTP requests to a logic class.
2. **View logic** (`ACA001SFLogic`) processes the request — currently as an empty stub, but intended to populate the data model.
3. **Data bean** (`ACA001SFBean`) carries the prepared data to the presentation layer.
4. **JSP views** render the bean's properties to the user.

The naming convention (`ACA001SF`) follows an `ACA` prefix pattern used throughout the package, indicating a family of similarly structured modules. Future sub-modules are expected to follow the same bean-logic-JSP pattern, each handling a distinct business feature.

### Module relationships

The sub-modules relate through shared architectural patterns and framework conventions:

- All modules are configured as Struts-style actions via XML, meaning they share a common request routing mechanism.
- The bean-logic separation creates a clean boundary between data presentation and processing logic, making each sub-module independently extensible.
- JSP views within a sub-module consume their own bean and logic classes, keeping sub-modules self-contained while sharing the same presentation technology (JSP).

## Key Patterns and Architecture

### MVC flow pattern

The architecture follows a classic server-side MVC pattern:

```mermaid
flowchart TD
    User["User / Browser"] -->|HTTP Request| XMLConf["XML Action Config<br/>(WEBGAMEN_*.xml)"]
    XMLConf --> Logic["View Logic<br/>(*Logic.execute())"]
    Logic -->|Populates| Bean["Data Bean<br/>(*Bean)"]
    Bean -->|Request scope| JSP["JSP Views"]
    JSP -->|HTML Response| User
```

The expected flow for any sub-module:

1. An incoming HTTP request arrives at the application server.
2. The XML action configuration resolves the request to a specific `*Logic` class.
3. `execute()` processes the request (populates beans, manages state).
4. A `*Bean` is placed into request or session scope.
5. Control is forwarded to a JSP view that reads the bean's properties.
6. The rendered HTML is returned to the user.

### JavaBeans data model

Data is carried between the logic and view layers through JavaBeans. Beans follow the standard convention: a private field with a public getter method. This allows JSP EL (Expression Language) and tag libraries to read properties seamlessly. Beans are currently read-only (no setters defined), meaning they transport data from logic to views but do not capture user input back.

### XML-driven action mapping

Request routing is declarative — controlled by XML configuration files rather than annotations or code. This approach means:

- New action mappings can be added by editing XML without recompiling Java code.
- The mapping files serve as a single source of truth for route definitions.
- Changes to routing require a configuration reload or application restart.

## Dependencies and Integration

### Internal dependencies

The `eo.web.webview` package depends on the broader application infrastructure:

- **Struts framework** (inferred) — the XML action configuration pattern and `*Logic` naming convention are characteristic of Struts 1.x.
- **JSP/Servlet API** — JSP views compile to servlets at runtime; all standard `javax.servlet` and `javax.servlet.jsp` APIs are available.
- **Application business layer** — while not yet connected in `ACA001SF`, future logic classes are expected to delegate to service/domain layers for data access and business processing.

### External dependencies

No third-party library dependencies are present in the current code. The module relies exclusively on the Java EE platform and the application's internal framework.

### Integration with the broader system

```mermaid
flowchart LR
    Browser["Browser"] -->|HTTP| Webview["eo.web.webview"]
    Webview -->|Routes via XML| Logic["*Logic classes"]
    Logic -->|Populates| Bean["*Bean classes"]
    Bean -->|Request scope| JSP["JSP views"]
    JSP -->|HTML| Browser
    Logic -.->|Future: delegates to| Services["Application services<br/>(business layer)"]
    Services -.->|Query| Data["Data layer<br/>(database, cache)"]
```

## Notes for Developers

- **Skeleton stage**: The only implemented sub-module (`ACA001SF`) is a placeholder. Real logic has not yet been written into `execute()` methods. New feature development should start by implementing the logic class first.
- **Read-only beans**: Current beans define only getters, not setters. If a view needs to accept user input that binds back to a bean, a `setValue(String)` method must be added.
- **Naming conventions**: Sub-modules follow the `ACA` prefix convention. New modules should follow the same `*Bean` / `*Logic` / JSP naming pattern for consistency.
- **Extensibility**: The package has no child sub-packages of its own — all extension happens by creating new sub-packages under `eo.web.webview` (e.g., a new feature area as `eo.web.webview.ACA002SF`).
- **No package-level dependencies**: The webview package has no outgoing dependencies beyond the Java EE platform. If new features require business logic, introduce dependencies on the appropriate service or domain packages.
- **Configuration management**: Action routing is managed through XML files. New sub-modules require corresponding entries in the action configuration XML.