# Eo

## Overview

The `eo` package represents the top-level package of the application codebase. It contains the application's web presentation layer and serves as the root namespace for all modules beneath it. At the time of this writing, the primary child module is `eo.web`, which implements the user-facing UI using **JavaServer Faces (JSF)** — providing the bridge between end users and the application's business logic.

The `eo` module's responsibility is to present data to users, capture their input, and delegate actions to the appropriate logic and service layers. It does not contain business rules or data access logic itself; those live in downstream packages that the web layer depends on indirectly through JSF's managed-bean injection.

## Sub-module Guide

### `eo.web` — Web Presentation Layer

The `eo.web` package implements the application's MVC-style view layer on top of JSF. It is responsible for:

- Rendering user-facing pages as JSP view templates
- Exposing data through EL-accessible managed beans
- Capturing user input and triggering actions via dedicated logic classes
- Delegating to higher-level business services for actual work

Within `eo.web`, the `webview` sub-package is the primary (and currently only) module, containing individual view sub-modules — each one mapping to a distinct screen or form in the application.

#### View sub-modules

Individual view sub-modules follow a consistent naming convention (`<ModuleCode>SF`, such as `ACA001SF`) and each contains three components:

| Component | Role |
|---|---|
| **Managed Bean** (e.g., `ACA001SFBean`) | Exposes data properties as JavaBean getters/setters, accessible to JSP pages via EL expressions like `#{aCA001SFBean.value}` |
| **Action Logic Class** (e.g., `ACA001SFLogic`) | Handles user actions via an `execute()` method entry point; delegates to business/service layers |
| **JSP View Page** | Renders the UI, pulling data from the bean through EL expressions |

#### Sub-module relationships

All view sub-modules are structurally identical siblings — they share the same architectural pattern but differ in content and configuration. They relate to each other in two key ways:

1. **Shared configuration**: Beans across all views are registered in common XML descriptors (`faces-config.xml`, plus module-specific files like `WEBGAMEN_*.xml`), creating a unified bean lifecycle.
2. **Shared presentation infrastructure**: All views pull from the same JSF framework, EL evaluation engine, and JSP rendering pipeline.

This means changes to the view-layer pattern (e.g., how beans are registered, how the `execute()` convention is applied) propagate uniformly across all views, but each view can evolve its data and behavior independently.

## Key Patterns and Architecture

### The JSF MVC Pattern

Every view within `eo` adheres to a three-tier MVC structure:

1. **View Layer** — JSP pages render the UI, pulling data from beans through EL expressions.
2. **Model Layer** — Plain Java beans act as view models, exposing properties as getters (and optionally setters).
3. **Controller Layer** — Dedicated logic classes handle user actions through an `execute()` entry point.

This keeps the presentation layer thin and focused on view concerns, while business logic resides in the logic classes that views invoke.

```mermaid
flowchart TD
    USER["End User"] --> JSP["JSP View Page"]
    JSP --> BEAN["Managed Bean
EL-accessible properties"]
    JSP --> LOGIC["Action Logic Class
execute() entry point"]
    BEAN --> JSP
    LOGIC --> SVC["Business / Service Layer
external to eo.web"]
    SVC --> LOGIC
```

### Data Flow

Data flows bidirectionally between the managed beans and JSP views:

- **Read (view-to-model)**: Beans expose properties via getters; the JSP reads them through EL.
- **Write (model-to-view)**: If a bean exposes both a getter and a setter, form data binds back to the bean. If only a getter exists, the property is display-only.

When a user triggers an action (form submit, button click), the `execute()` method on the logic class is invoked. This method delegates to external business services, then returns — the response flows back through the bean to the JSP for re-rendering.

```mermaid
flowchart LR
    USER["User interaction"] --> JSP["JSP View Page"]
    JSP --> BEAN["Managed Bean
getters / setters"]
    JSP --> LOGIC["Logic Class
execute()"]
    LOGIC --> SVC["Service /
Business Layer"]
    SVC --> LOGIC
```

### Managed Bean Registration

Beans are registered across multiple XML configuration files:

- `faces-config.xml` — the global JSF configuration
- Module-specific descriptors (e.g., `WEBGAMEN_FULL_ACA001.xml`, `x33S_ACA001.xml`)

When adding a new view, the bean must be declared in the appropriate descriptor so that JSF can instantiate it and EL can resolve references.

### Bean Property Patterns

| Pattern | Behavior |
|---|---|
| **Read-only** — getter without setter | Views display data but cannot write it back through EL |
| **Read-write** — both getter and setter | Enables form data binding; user input flows back into the bean |

## Dependencies and Integration

### How `eo` connects to the rest of the system

```mermaid
flowchart LR
    Eo["eo package
(root namespace)"] --> Web["eo.web
JSF presentation layer"]
    Web --> Webview["eo.web.webview
view sub-modules"]
    Webview --> JSP["JSP view pages"]
    Webview --> Beans["Managed Beans"]
    Webview --> Logic["Action Logic Classes"]
    Logic --> ExtSVC["External services
(business / data layers
outside eo)"]
```

**Inbound dependencies**: The webview sub-modules are consumed by XML configuration files (`faces-config.xml`, `WEBGAMEN_*.xml`, `x33S_*.xml`) that declare managed beans, and by JSP view pages that reference beans via EL expressions.

**Outbound dependencies**: At the package level, no outgoing Java imports have been detected from source files in this package. This indicates that sub-modules depend on external logic and services through JSF's dependency injection or lookup mechanisms rather than direct imports. The actual business logic and data access layers live outside `eo.web` and are accessed indirectly.

### Relationship to other layers

The `eo` package sits at the top of the application's layered architecture, directly serving HTTP requests and rendering responses. Its relationship to other layers is mediated through the JSF framework: managed beans receive their dependencies (service layers, data access objects) through configuration or annotation-based injection, while logic classes delegate to higher-level business services.

## Notes for Developers

- **Scaffolds awaiting implementation**: Sub-modules like `ACA001SF` are essentially scaffolds. Managed beans may lack setters, and logic classes may have empty `execute()` methods (often annotated with comments like "Futurity view logic" as placeholders). Before implementing functionality, verify what is wired up versus what is placeholder.
- **Read-only bean properties**: If a managed bean exposes only a getter without a setter, views can display data but cannot write it back via EL. Adding a setter is the standard fix if form data binding is required.
- **Multiple source copies**: Some logic classes may exist in multiple locations (e.g., full fixture vs. XML unresolved-FQN variants). Check your build configuration to ensure you are editing the correct variant.
- **JSF configuration**: Managed beans are wired through XML descriptors. When adding new views, ensure they are registered in the appropriate configuration file.
- **Extension point**: The `execute()` method on logic classes is the designated entry point for action logic. Add business logic there rather than inline in the JSF page or managed bean.
- **No source files indexed at the parent level**: The parent module `eo` has no directly indexed source files; all concrete implementations live within sub-modules (primarily `eo.web.webview`). Focus exploration on individual sub-module wiki pages for specific views.
- **Consistent naming convention**: Sub-modules follow the pattern `<ModuleCode>SF` (e.g., `ACA001SF`), and their beans/logic classes mirror this naming (`ACA001SFBean`, `ACA001SFLogic`).