# Eo / Web / Webview

## Overview

The `eo.web.webview` package is a JSF (JavaServer Faces) webview subpackage within the `eo.web` tier of the application. It provides backing beans and view-logic controllers that bridge the presentation layer (JSP/JSF views) with business processing. Each sub-package in this module typically represents a single application page or feature area, following a consistent pattern: a managed bean for view state and a logic class for action handling.

The module's primary responsibility is to implement the server-side rendering and action dispatch for web-facing features. In this codebase, it serves as a collection of self-contained view modules, each wired into the JSF navigation framework through `faces-config.xml` and other XML configuration files.

## Sub-module Guide

The `webview` package contains feature-specific sub-packages. The following child modules are documented in detail:

- **[`ACA001SF`](eo/web/webview/ACA001SF.md)** — The "Futurity" feature page. This sub-package provides the JSF backing bean and action handler for a page referred to as "Futurity." It is one of the more prominently wired components in the module, referenced by multiple XML configuration files across different deployment profiles.

### How the sub-modules relate

Each sub-package under `eo.web.webview` follows a uniform two-class pattern:

1. A **Bean** class — a standard JSF managed bean that holds view state and exposes it via public getters for EL (Expression Language) access in JSP/JSF pages.
2. A **Logic** class — the page controller whose `execute()` method handles user actions (form submissions, button clicks) triggered from the associated view.

This uniformity means that adding a new feature to the webview layer involves creating a new sub-package with a Bean/Logic pair and registering them in the relevant XML configs. There is no shared abstraction layer between sub-modules; each is independently wired and independently deployed.

```mermaid
flowchart TD
    user["User / Browser"] --> jsp["JSP/JSF View"]
    jsp --> bean["Managed Bean"]
    jsp --> logic["Logic Class"]
    logic --> fc["faces-config.xml"]
    bean --> fc
    fc --> outcome["Navigation Outcome"]
    outcome --> jsp
```

## Key Patterns and Architecture

### JSF Page Controller Pattern

The module adheres to the JSF Page Controller pattern. For any given feature page:

- The **Bean** holds the data the view needs to render. It is typically a lightweight POJO — often with just one or a few fields — exposing getters (and occasionally setters) for EL access.
- The **Logic** class provides the `execute()` method that the JSF framework invokes when the user triggers an action. The method returns `void`, and navigation is driven by outcome mappings in `faces-config.xml` rather than a return string.

### Minimal Data Model

Sub-modules in this package tend to be data-light. The `ACA001SF` bean, for example, holds a single `String` field with no setter — exposing just enough state for the view to render and for the logic class to act upon. This simplicity is intentional: the bean is a conduit, not a domain model.

### XML-Driven Wiring

All sub-packages are wired into the JSF lifecycle through XML configuration rather than annotation-based discovery:

- **faces-config.xml** — Registers the managed bean and defines navigation rules.
- **Custom XML configs** (e.g., `WEBGAMEN_FULL_ACA001.xml`, `x33S_ACA001.xml`, `external-refs.xml`) — Reference both the bean and logic classes, suggesting feature flags, deployment profiles, or environment-specific toggling.

This approach means that changing a sub-package's bean name, method signature, or visibility requires updating every XML reference. It also means the wiring is visible in version control as structured configuration rather than inferred from annotations.

## Dependencies and Integration

### Internal Dependencies

- **`eo.web` (parent package)** — The `webview` subpackage sits under the broader `eo.web` tier, which likely contains shared web infrastructure (filters, servlets, interceptors). Sub-packages within `webview` are self-contained and do not import from sibling packages.
- **JSF framework** — The classes in this module depend on the JavaServer Faces API for managed bean semantics, EL resolution, and the faces-config.xml lifecycle.

### External Configuration

Each sub-package is referenced by multiple XML configuration files. The `ACA001SF` module alone is wired into at least five distinct XML configs:

| Configuration File | References |
|---|---|
| `faces-config.xml` | Managed bean registration |
| `WEBGAMEN_FULL_ACA001.xml` | Bean + Logic |
| `WEBGAMEN_ACA001010PJP.xml` | Bean + Logic |
| `x33S_ACA001.xml` | Bean + Logic |
| `external-refs.xml` | Logic |

This broad wiring suggests the sub-module is active across multiple feature profiles or deployment configurations. Any changes to bean or logic signatures require coordinated updates across all these files.

### Integration with the Web Tier

The `webview` module is the presentation-layer entry point for its features. JSP pages in the web module reference the managed beans via EL expressions (e.g., `#{aca001sFBean.value}`), and the JSF framework resolves user actions to the corresponding logic classes. The full flow:

1. A user navigates to the page (e.g., `FULL_ACA001010PJP.jsp`).
2. JSF instantiates the managed bean and makes it available via EL.
3. The JSP renders using data from the bean.
4. User actions dispatch to the logic class's `execute()` method.
5. Navigation outcomes are resolved by `faces-config.xml` rules.

```mermaid
flowchart LR
    browser["Browser"] --> jsp["JSP/JSF View"]
    jsp --> bean["Bean: ACA001SFBean"]
    jsp --> logic["Logic: ACA001SFLogic"]
    bean --> xml["faces-config.xml"]
    logic --> xml
    xml --> redirect["Next View"]
```

## Notes for Developers

- **Empty method bodies are common.** The `ACA001SFLogic.execute()` method currently has no implementation. This is likely scaffolding or a placeholder — if you are adding functionality to the Futurity view, `execute()` is the correct entry point.
- **Bean fields may be read-only.** Some beans (like `ACA001SFBean`) expose only getters, not setters. If you need to set a bean field from the logic class, you will need to add a setter or pass the bean by reference.
- **XML wiring is pervasive.** Each sub-package is referenced by multiple XML configuration files. Before changing a bean name, method signature, or visibility modifier, verify all XML references that would be affected.
- **Two source trees.** Some classes (notably `ACA001SFLogic`) appear in both the main source tree (`full-fixture-codebase`) and a stubbed/unresolved source tree (`xml-unresolved-fqn`). Confirm which version is active in your build configuration.
- **Adding a new feature.** To create a new webview page, follow the existing pattern: create a sub-package with a `*Bean` class (view state) and a `*Logic` class (action handler), then register both in `faces-config.xml` and the relevant custom XML configs.
- **No child modules beyond what's documented.** This module does not currently contain further sub-decomposition beyond the feature-specific sub-packages like `ACA001SF`.