# Eo / Web

## Overview

The `eo.web` package is the web presentation layer of the application. It serves as the entry point where end users interact with the system through browser-rendered views built on JavaServer Faces (JSF). At present, its sole sub-module — `eo.web.webview` — provides a configuration-driven MVC layer that maps individual business views to backing beans, logic classes, and JSP pages. This appears to be a legacy or scaffolding-style web tier rather than a modern SPA architecture; views are lightweight, configuration-heavy, and designed for straightforward page-by-page business display.

## Sub-module Guide

### Webview — The JSF View Layer

The `eo.web.webview` package implements the core web presentation logic. It is responsible for rendering business-focused views to end users through the classic JSF MVC pattern. Each sub-view (e.g., `ACA001SF` — the "Futurity" view) is a self-contained unit consisting of:

- **A backing bean** — A JSF-managed POJO that exposes properties via getters. Beans tend to be lean, with read-only properties that prevent two-way data binding from user input.
- **A logic class** — A dedicated class with an `execute()` method that the bean delegates to during the JSF lifecycle. These methods are currently no-ops, suggesting they serve as extension points for future business logic.
- **A JSP view page** — The rendered UI that uses EL expressions to read bean properties and invoke logic.
- **XML configuration files** — Multiple XML files (`faces-config.xml`, `WEBGAMEN_*.xml`, `x33S_*.xml`) manage managed-bean registration, action mappings, and external wiring.

The `ACA001SF` sub-module, for example, implements a display-only "Futurity" page where the bean carries a single read-only `String` value and the logic class has an empty `execute()` body. This pattern holds across all current sub-modules: scaffolding views that define structure but await data-loading and interaction logic.

### How Sub-modules Relate

Within `eo.web.webview`, each sub-view operates as an independent unit. Views do not communicate directly; navigation between them is handled by JSF's navigation outcome mechanism (though current `void` return types on `execute()` methods limit this). Views are wired together only through shared JSF configuration files and the common XML-based bean lifecycle.

```mermaid
flowchart TD
    subgraph WebView["Webview Module"]
        JSP["JSP View Pages"]
        BEAN["Backing Beans"]
        LOGIC["View Logic Classes"]
        CONFIG["XML Configuration"]
    end

    subgraph EoWeb["Eo / Web Package"]
        JSP
        BEAN
        LOGIC
        CONFIG
    end

    JSP -->|EL reads properties| BEAN
    JSP -->|invokes actions| LOGIC
    BEAN -->|delegates| LOGIC
    CONFIG -->|registers beans| BEAN
    CONFIG -->|maps actions| LOGIC
```

## Key Patterns and Architecture

### MVC via JSF Backing Beans

Each view follows a clean separation: the bean is the "M" (model, exposing UI state), the logic class is the "C" (controller, processing actions), and the JSP is the "V" (view, rendering HTML). This keeps concerns distinct and makes each component independently testable.

### Read-Only Bean Properties

Beans like `ACA001SFBean` expose getters without setters, making them suitable for display-only data. This is a deliberate pattern that prevents two-way binding from user input, channeling all data population through the logic layer.

### No-op Logic Stubs

The `execute()` methods in logic classes are currently no-ops. This suggests the framework uses these as extension points — developers add business logic here when a view needs data loading, validation, or processing.

### Configuration-Driven Wiring

JSF managed beans are registered across multiple XML files rather than via annotations. This means bean lifecycle, scope, and navigation outcomes are defined externally, which can simplify centralized configuration but requires checking all relevant XML files when modifying behavior.

### Dual Source Trees

Some logic classes appear in both a "full-fixture-codebase" and an "xml-unresolved-fqn" source tree, with identical signatures but varying Javadoc coverage. The canonical version is the full-fixture variant.

## Dependencies and Integration

### Inbound Dependencies

This module consumes no internal package dependencies. Classes import only from the Java standard library, keeping the module lightweight and decoupled from application-specific services.

### Framework Dependencies

- **JSF (JavaServer Faces)** — The view framework providing backing bean lifecycle, EL evaluation, and navigation.
- **JSP** — The view rendering technology, with pages using EL expressions to bind to bean properties.
- **XML configuration** — Multiple XML files manage managed-bean registration, action mappings, and external wiring.

### Outbound

No outbound internal dependencies were detected. The module is self-contained within the Java standard library and JSF framework APIs.

## Notes for Developers

- **Extend logic, not beans** — When adding functionality to a view, start in the logic class's `execute()` method. Beans should remain lean, exposing only the state the view needs to render.
- **Read-only by design** — If a bean has no setter, user input cannot be two-way-bound. Adding a `setValue()` method following standard JSF conventions is required if two-way binding is needed.
- **Check all XML config files** — Configuration for a view may be spread across `faces-config.xml`, `WEBGAMEN_*.xml`, `x33S_*.xml`, and `external-refs.xml`. Changes to managed-bean settings should be reviewed in all four files to avoid conflicts or overwrites.
- **Navigation limitation** — `execute()` returns `void`, so it cannot produce a JSF navigation outcome string. Navigation must instead be handled by modifying bean state that JSF reads, or by calling `ExternalContext.redirect()` from within the logic method.
- **Two source trees** — When modifying a logic class, update the canonical version in `full-fixture-codebase`. The `xml-unresolved-fqn` variant is a derived copy and may lack Javadoc that exists in the primary source.
- **Naming convention** — Sub-module names follow an `ACA + N + SF` pattern (e.g., `ACA001SF`). The prefix and numeric suffix likely correspond to internal feature or requirement identifiers. The domain label in the Javadoc (e.g., "Futurity") provides additional context about the business area the view serves.