# Eo / Web / Webview / Aca001sf

## Overview

`ACA001SF` is a Java EE / JSF webview subpackage that renders the "Futurity" page (as indicated by the logic class's class-level Javadoc). It follows a standard JSF MVC pattern: a [bean](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/ACA001SFBean.java) holds page-scoped data, and a [logic](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/ACA001SFLogic.java) class acts as the action handler invoked when the page is submitted or requested. Both are wired up via XML configuration files (`faces-config.xml`, `WEBGAMEN_FULL_ACA001.xml`, etc.) and consumed by JSP view files such as [FULL_ACA001010PJP.jsp](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/FULL_ACA001010PJP.jsp).

## Key Classes

### ACA001SFBean

**Source:** [ACA001SFBean.java](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/ACA001SFBean.java)

This class is a JSF managed bean (or CDI backing bean). It is the simplest possible data carrier for the page — a single `String` field with a standard getter:

```java
public class ACA001SFBean {
    private String value;
    public String getValue() { return value; }
}
```

- **`getValue()`** — Returns the current value of the `value` field. No parameters; returns a `String`. This is the only property exposed to JSF expression language (`#{aca001sfBean.value}`), which means the JSP binds its input/output fields to this single property.
- **Purpose:** Acts as the model/view data bridge for the Futurity page. In a typical JSF lifecycle, JSF will instantiate this bean (via the XML config wire-ups described below), inject or read form data into `value`, and render it back to the JSP.

The bean is referenced by 4 XML config files and 2 JSP views, making it a central piece of this module's wiring.

### ACA001SFLogic

**Source (full-fixture):** [ACA001SFLogic.java](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/ACA001SFLogic.java)
**Source (xml-unresolved-fqn variant):** [ACA001SFLogic.java](xml-unresolved-fqn/src/java/eo/web/webview/ACA001SF/ACA001SFLogic.java)

This class serves as the action/execution handler for the page. The full-fixture variant includes a class-level Javadoc comment describing it as **"Futurity view logic"**:

```java
/** ACA001SFLogic — Futurity view logic */
public class ACA001SFLogic {
    public void execute() {}
}
```

- **`execute()`** — The single public method, returning `void`. In the current source tree the method body is empty, which suggests either:
  - The business logic is delegated to other layers/services not present in this module.
  - This is a placeholder scaffold where the actual logic will be implemented.
  - The behavior is configuration-driven rather than code-driven.

- **Purpose:** Invoked by the JSF framework when the user interacts with the page (e.g., clicks a command button or link bound to this action method). The method name `execute` is a conventional JSF action handler name.

There are two versions of this class in the codebase — one in the full-fixture source tree and another in the `xml-unresolved-fqn` variant tree. The latter is a minimal variant without the Javadoc comment but has the same structure. Both are referenced by 4 XML configs (the full-fixture version is also referenced by 1 JSP).

## How It Works

The typical request flow for the Futurity page follows the JSF lifecycle:

1. **Navigation** — A user navigates to the page (e.g. `FULL_ACA001010PJP.jsp`). The JSP references both the bean and the logic class directly in its view code.
2. **Bean binding** — JSF resolves `ACA001SFBean` via the XML configuration entries in `faces-config.xml` and the module-specific configs (`WEBGAMEN_FULL_ACA001.xml`, `WEBGAMEN_ACA001010PJP.xml`, `x33S_ACA001.xml`). The bean is placed into an appropriate scope (request, session, or view).
3. **Rendering** — The JSP reads `#{aca001sfBean.value}` to display content or bind form inputs to the bean's `value` property.
4. **Form submission / action** — When the user submits the page, JSF invokes `ACA001SFLogic.execute()` as the action handler. The logic class can perform business operations and then update the bean or forward to the next view.
5. **Redisplay** — JSF re-renders the page with the updated bean state.

```mermaid
flowchart LR
    JSP["FULL_ACA001010PJP.jsp"] --> BEAN["ACA001SFBean"]
    JSP --> LOGIC["ACA001SFLogic"]
    BEAN --> XML1["WEBGAMEN_FULL_ACA001.xml"]
    BEAN --> XML2["WEBGAMEN_ACA001010PJP.xml"]
    BEAN --> XML3["x33S_ACA001.xml"]
    BEAN --> XML4["faces-config.xml"]
    LOGIC --> XML1
    LOGIC --> XML2
    LOGIC --> XML3
    LOGIC --> XML5["external-refs.xml"]
```

## Data Model

The data model for this module is minimal:

| Property | Type | Bean | Direction |
|---|---|---|---|
| `value` | `String` | [ACA001SFBean](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/ACA001SFBean.java) | Read/Write |

The `value` field is the sole data point flowing between the view and the logic layer. In a JSF page, this would typically be bound to a single input component (e.g., `<h:inputText value="#{aca001sfBean.value}"/>`) or used as a display value.

## Dependencies and Integration

### External Wiring (XML Configuration)

The module is tightly integrated into the application's XML-based configuration ecosystem:

| Config File | Referenced Classes |
|---|---|
| [WEBGAMEN_FULL_ACA001.xml](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/WEBGAMEN_FULL_ACA001.xml) | `ACA001SFBean`, `ACA001SFLogic` |
| [WEBGAMEN_ACA001010PJP.xml](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/WEBGAMEN_ACA001010PJP.xml) | `ACA001SFBean`, `ACA001SFLogic` |
| [x33S_ACA001.xml](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/x33S_ACA001.xml) | `ACA001SFBean`, `ACA001SFLogic` |
| [faces-config.xml](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/faces-config.xml) | `ACA001SFBean` |
| [external-refs.xml](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/external-refs.xml) | `ACA001SFLogic` |

- `faces-config.xml` typically registers the bean as a managed bean (defining its scope, e.g., `@RequestScoped` or `@ViewScoped`).
- `WEBGAMEN_*` and `x33S_*` XML files likely define page navigation rules, security constraints, or module-specific configurations.
- `external-refs.xml` references the logic class, suggesting it may be exposed to other modules or external callers.

### View Layer

| JSP | Referenced Classes |
|---|---|
| [FULL_ACA001010PJP.jsp](full-fixture-codebase/src/java/eo/web/webview/ACA001SF/FULL_ACA001010PJP.jsp) | `ACA001SFBean`, `ACA001SFLogic` |

This JSP is the primary view for the Futurity page and references both the bean and the logic class directly.

### Cross-module Relationships

This module does not import any Java packages from other modules (no inter-module Java dependencies). Its integration is entirely through XML wiring and JSP view composition, which is typical of JSF 1.x / Java EE web applications.

## Notes for Developers

- **Empty action handler.** The `execute()` method body is currently empty. If you are extending this page, this is likely the method you will populate with business logic.
- **Single property.** The bean exposes only one property (`value`). If the page needs additional fields, you will need to add new private fields and corresponding getters/setters following the JavaBeans convention.
- **Dual source trees.** `ACA001SFLogic` exists in both the `full-fixture-codebase` and `xml-unresolved-fqn` trees. Be aware of which source tree you are modifying — they diverge on the presence of the class-level Javadoc comment.
- **JSF-managed bean scope.** The bean's scope is determined by `faces-config.xml`. If you need the bean to persist across multiple requests, verify the scope configuration there (e.g., change from `request` to `session` scope).
- **XML-heavy wiring.** Adding or modifying the bean or logic class requires updates to the relevant XML config files to maintain correct wiring. Do not assume the bean is automatically discoverable without XML registration.
- **Package naming convention.** The package name `eo.web.webview.ACA001SF` follows a pattern where `ACA001SF` is a specific screen/function code. New screens in this module would follow the same naming pattern (e.g., `ACA002SF`, `ACA003SF`).