# Eo / Web

## Overview

The `eo.web` package is a JSF-based web presentation layer responsible for rendering server-side views within the application. It follows a classic MVC (Model-View-Controller) pattern where backing beans provide the data model, JSP/JSF pages handle rendering, and action classes mediate user interactions. This module serves as the top-level grouping for all web-facing components and delegates view-specific functionality to its sub-modules, most notably the `webview` sub-package.

At a high level, `eo.web` does not contain standalone source files itself — its content is organized entirely through child sub-modules (under `eo.web.webview`), each of which owns its own beans, logic classes, configurations, and view pages. This packaging approach keeps concerns modular: each view feature lives in its own namespace with all artifacts co-located.

## Sub-module Guide

### webview

The `webview` sub-package is the core of `eo.web` and currently contains one indexed sub-module: **ACA001SF**.

**ACA001SF** (Futurity View) is a structural scaffold for a JSF-based page. It consists of:

- **`ACA001SFBean`** — a JSF managed backing bean exposing a single read-only `String` property (`value`) bound via EL expressions in JSP views.
- **`ACA001SFLogic`** — an action/controller class with an `execute()` entry point for form submissions. Currently a no-op placeholder intended to be expanded as the feature matures.

The sub-module is integrated into the application through five XML configuration files (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `external-refs.xml`) and at least two JSP views. The multiple registration paths suggest the same components can operate under different scopes or initialization parameters depending on which config profile is active.

### How the pieces relate

All sub-module content under `eo.web.webview` follows a single, consistent pattern: one sub-package per view, each with its own backing bean, logic class, and JSP views. ACA001SF is the only indexed instance today, but the structure is designed to accommodate additional view sub-modules. Each new sub-module would slot in as an independent namespace under `eo.web.webview`, maintaining the same bean-logic-view triad without cross-talk with sibling modules.

## Key Patterns and Architecture

### JSF MVC Triad

Every view sub-module adheres to a three-part structure:

1. A **backing bean** that exposes properties via getters/setters for JSP EL binding.
2. A **logic/action class** that processes server-side actions (form submissions, navigation decisions).
3. **JSP/JSF view pages** that render the UI and wire to the bean via EL expressions.

This keeps presentation, data, and action logic cleanly separated within each sub-module's namespace.

### Request Flow

```mermaid
flowchart TD
    A["Request Flow"] --> B["User navigates to page"]
    B --> C["JSF resolves backing bean"]
    C --> D["JSP renders view via EL expressions"]
    D --> E["Action dispatched to logic class.execute()"]
    E --> F["Processes action, may trigger state changes"]

    subgraph Core["Core Components"]
        G["Backings bean
JSF managed bean"]
        H["Logic class
Action/controller"]
    end

    subgraph Config["XML Configuration"]
        I["faces-config.xml"]
        J["WEBGAMEN config"]
        K["x33S config"]
        L["external-refs.xml"]
    end

    subgraph Views["JSP Views"]
        N["JSP page 1"]
        O["JSP page 2+"]
    end

    I --> G
    J --> G
    J --> H
    K --> G
    L --> H
    N --> G
    N --> H
    O --> G
    O --> H
    G --> H
```

### Multiple Registration Paths

Components are registered across several XML configuration files, which appears intentional. This allows the same view components to operate under different scopes (request, view, session, application) or initialization parameters depending on which config profile is active. Developers should inspect each XML file to understand the lifecycle context for a given bean.

### Dual Source Variants

Some logic classes exist in dual source paths — a full-fixture source and an XML-unresolved-FQN source. Both share identical implementations but differ in Javadoc presence. This suggests a multi-branch or multi-profile build strategy. Changes to shared logic should be applied consistently across both paths to avoid divergence.

## Dependencies and Integration

### Inbound

- **XML configurations** — `faces-config.xml` and several specialized XML config files register backing beans and actions, wiring them into the JSF lifecycle.
- **JSP view pages** — View pages bind directly to backing beans and logic classes via EL expressions, driving the presentation layer.

### Outbound

The current implementations are stubs and do not import or reference any external services, repositories, or application components. New services required as features expand should be wired through dependency injection or XML configuration.

## Notes for Developers

- **Stub-level implementations.** The backing beans and logic classes are scaffolds. The `execute()` method on the logic class is the primary extension point — business logic should be added there as features grow.
- **Read-only bean properties.** The backing bean exposes a getter but no setter. If the view needs to accept user input, a setter should be added or the field should be populated via `@PostConstruct` initialization or DI injection.
- **Multiple configs, multiple lifecycles.** The same classes are registered in several XML files with potentially different scopes. Verify each config's scope and initialization parameters before relying on behavior.
- **Keep sub-modules self-contained.** The convention of one sub-package per view under `eo.web.webview` keeps beans, logic, configs, and JSPs co-located. Follow this pattern when adding new views.
- **Watch dual source paths.** Some classes exist in multiple source paths. If you modify a shared logic class, check whether a corresponding file exists in the XML-unresolved-FQN source path and keep both in sync unless a clear canonical source has been designated.