# Eo / Web / Webview

## Overview

The `eo.web.webview` 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. Each sub-module under this package corresponds to a specific view in the application, following a consistent pattern: a JSF managed bean (the view model) paired with an action logic class (the controller), wired together through JSF configuration descriptors and consumed by JSP view pages.

This package serves as the bridge between the user interface and the application's business logic. Web views in this layer expose data via EL-accessible properties and expose actions that delegate to dedicated logic classes.

## Sub-module Guide

### ACA001SF

**ACA001SF** is a minimal JSF view module that provides a backing bean and action handler for the `ACA001`/`ACA001010PJP` views. It consists of two classes:

- **ACA001SFBean** — The view model. A JSF managed bean exposing a single read-only `value` property (String). It is registered via multiple XML configuration files and referenced from JSP views through EL expressions such as `#{aCA001SFBean.value}`.
- **ACA001SFLogic** — The action handler. An action-behavior class with an `execute()` method that serves as the entry point for user-triggered actions (form submissions, button clicks). Currently contains an empty body, indicating this is a scaffold awaiting implementation.

The module is referenced by four XML configuration files (`WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`, `faces-config.xml`), one JSP view page (`FULL_ACA001010PJP.jsp`), and one external reference file. Two copies of `ACA001SFLogic` exist in the codebase (one in the full fixture and one in the XML unresolved-FQN variant), but both are functionally identical.

ACA001SF follows the standard JSF managed-bean pattern: beans are wired via XML descriptors, views reference beans via EL, and action logic classes are invoked through JSF action bindings. It is the only indexed child module in this package, and the module-level statistics indicate no additional source files, classes, or methods have been catalogued beyond this sub-module.

## Key Patterns and Architecture

The webview package follows a **JSF managed-bean MVC pattern** consistently across its sub-modules:

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

The request flow for a typical view (such as ACA001SF) follows these steps:

```mermaid
flowchart LR
    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 / button click)"]
    D --> E["Action logic class
execute() is invoked"]
```

This pattern decouples the view rendering from business logic, allowing each view to evolve independently. The logic classes serve as the primary extension points for developers adding functionality to specific views.

### Data Flow

Data flows from the managed beans to the views through EL-accessible properties. In ACA001SF, the bean exposes only a single read-only property (`value`), suggesting the data is either injected externally or intended to be populated programmatically. The absence of a setter implies views can display data but cannot write it back directly through EL — any form data binding would require adding a setter method.

### Extension Points

The `execute()` method on logic classes (e.g., `ACA001SFLogic.execute()`) is the primary extension point for adding business logic to a view. In ACA001SF, this method is currently empty and annotated with a Javadoc comment reading "Futurity view logic," indicating it is a placeholder for future implementation.

## Dependencies and Integration

### Inbound Dependencies

The webview module's sub-modules are consumed by XML configuration files and JSP views. ACA001SF is referenced by:

| Referencing Artifact | Type |
|---|---|
| `WEBGAMEN_FULL_ACA001.xml` | XML config |
| `faces-config.xml` | JSF config |
| `WEBGAMEN_ACA001010PJP.xml` | XML config |
| `x33S_ACA001.xml` | XML config |
| `FULL_ACA001010PJP.jsp` | JSP view |
| `external-refs.xml` | External reference |

This indicates that each view is explicitly declared in JSF or module-specific XML descriptors, and its corresponding JSP page references the bean and logic class directly.

### Outbound Dependencies

At the package level, no outgoing imports have been detected from the source files in this package. This suggests that the sub-modules are self-contained view components that depend on external logic and services only through the JSF framework's dependency injection or lookup mechanisms, rather than direct Java imports.

### Relationship to the Broader System

The webview package sits at the top of the application's layered architecture, directly serving HTTP requests and rendering responses. Its relationship to other layers appears to be mediated through the JSF framework: managed beans receive their dependencies (e.g., service layers, data access objects) through configuration or annotation-based injection, while logic classes delegate to higher-level business services. This keeps the presentation layer thin and focused on view concerns.

## Notes for Developers

- **Stubs 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**: Be aware that 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 (`faces-config.xml` and module-specific XMLs). 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.webview` has no directly indexed source files; all concrete implementations live within sub-modules. Focus exploration on individual sub-module wiki pages for specific views.