# Eo

## Overview

The `eo` package represents 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). The module is lightweight and decoupled from internal application services, importing only from the Java standard library. This appears to be a legacy or scaffolding-style web tier rather than a modern SPA architecture; views are configuration-heavy and designed for straightforward page-by-page business display.

Within the `eo` package, the `eo.web` sub-package is the sole direct child. It implements the core web presentation logic, delegating view rendering to `eo.web.webview` -- a configuration-driven MVC layer that maps individual business views to backing beans, logic classes, and JSP pages.

```mermaid
flowchart TD
    subgraph EO
        WEB["Web Package"]
        subgraph Webview_Module
            JSP["JSP View Pages"]
            BEAN["Backing Beans"]
            LOGIC["View Logic Classes"]
            CONFIG["XML Configuration"]
        end
        WEB --> Webview_Module
        JSP -->|EL reads properties| BEAN
        JSP -->|invokes actions| LOGIC
        BEAN -->|delegates| LOGIC
        CONFIG -->|registers beans| BEAN
        CONFIG -->|maps actions| LOGIC
    end
```

## Sub-module Guide

### Web (`eo.web`) / Webview (`eo.web.webview`)

The `eo.web` package is the web presentation package, and within it, `eo.web.webview` is the core module that implements the 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.

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.

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.

## 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.

### Sub-view 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.

## 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.
- **Scaffolding state** -- The current sub-modules are largely scaffolding views with no-op logic. This appears to be an active area of development, with structure in place but business logic yet to be implemented.