# Eo / Web

## Overview

The `eo.web` package is the web presentation layer of the application, built on **JavaServer Faces (JSF)**. It provides the MVC-style view components that render user-facing pages and handle user interactions. This package serves as the bridge between the user interface and the application's business logic — exposing data via EL-accessible properties, capturing user input, and delegating actions to dedicated logic classes.

The layer follows a consistent JSF managed-bean pattern across all its sub-modules: a managed bean (view model) paired with an action logic class (controller), wired together through JSF XML configuration descriptors and consumed by JSP view pages. This uniform structure allows each view to evolve independently while maintaining a predictable mental model for developers navigating the codebase.

Currently, the `eo.web.webview` sub-package is the primary — and at the time of this writing, the only — module within `eo.web`. It is itself a container for individual view sub-modules (such as ACA001SF), each of which maps to a specific user-facing page or form in the application.

## Architecture

### The JSF MVC Pattern

Every view in the `eo.web.webview` package adheres to the same three-tier structure:

1. **View Layer** — JSP pages render the UI, pulling data from beans through EL expressions.
2. **Model Layer** — Plain Java beans act as the view model, exposing data properties as getters (and optionally setters) that are accessible through EL.
3. **Controller Layer** — Dedicated logic classes handle user actions (form submissions, button clicks), with an `execute()` method serving as the entry point.

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

#### Request Flow

When a user navigates to a page, the following sequence occurs:

```mermaid
flowchart TD
    A["User navigates to JSP view page"] --> B["JSF instantiates
managed bean"]
    B --> C["JSP renders UI
using EL expressions"]
    C --> D["User triggers action
form submit or button click"]
    D --> E["Action logic class
execute() is invoked"]
```

The flow then continues into the logic class, which delegates to higher-level business services. The response flows back through the bean to the JSP for rendering.

### Data Flow

Data flows from the managed beans to the views through EL-accessible properties. Beans expose read-only or read-write properties via JavaBean conventions (getters and setters). If a bean exposes only a getter without a setter, views can display data but cannot write it back through EL — any form data binding requires adding a setter.

In many sub-modules, beans currently expose minimal or no properties, indicating they are scaffolds awaiting real data integration. The `execute()` method on the logic class is the primary extension point for populating data or triggering side effects.

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

### Sub-module Organization

The `eo.web.webview` package acts as a container for individual view sub-modules. Each sub-module represents a distinct screen or form in the application:

| Sub-module | Description |
|---|---|
| **ACA001SF** | A minimal JSF view for the ACA001/FULL_ACA001010PJP screens. Contains a managed bean (`ACA001SFBean`) and an action logic class (`ACA001SFLogic`). Currently a scaffold with an empty `execute()` method. |

Additional sub-modules may exist beyond what is currently indexed, following the same naming convention.

## Key Patterns and Architecture

### Managed Bean Registration

Beans are registered through 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 like `#{aCA001SFBean.value}`.

### Logic Class Extension Point

The `execute()` method on logic classes (e.g., `ACA001SFLogic.execute()`) is the designated entry point for action logic. Business logic should be added here rather than inline in the JSP page or managed bean. In current sub-modules, this method is often empty — annotated with comments like "Futurity view logic" — indicating placeholder scaffolds.

### Bean Property Patterns

Beans follow standard JavaBean conventions:
- **Read-only properties**: A getter without a setter (`getValue()` but no `setValue()`). Views display data but cannot write it back through EL.
- **Read-write properties**: Both getter and setter present. Enables form data binding where user input flows back into the bean.

### Extension and Integration Points

- **Adding a new view**: Create a bean class, a logic class, register the bean in the XML descriptor, and create the JSP page. Wire them together through EL.
- **Extending existing views**: Implement the `execute()` method in the logic class. Add properties to the bean as needed.
- **Business logic delegation**: Logic classes delegate to the application's service/data layers. The webview sub-modules are designed to be thin — they should not contain business rules themselves.

## Dependencies and Integration

### Inbound Dependencies

The webview module's sub-modules are consumed by:
- **XML configuration files** (`faces-config.xml`, `WEBGAMEN_*.xml`, `x33S_*.xml`) that declare managed beans
- **JSP view pages** that reference beans via EL expressions
- **External reference files** that may define cross-module wiring

### Outbound Dependencies

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

### Relationship to Other Layers

The `eo.web` 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. The managed beans may lack setters, and logic classes may have empty `execute()` methods. Before implementing functionality, verify what is actually 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.web` has no directly indexed source files; all concrete implementations live within sub-modules. 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`).