Use cases
From Eclipsepedia
Contents |
WTP JavaServer Faces Development Use Cases
Objective This document captures use cases for managing JavaServer Faces (JSF) artifacts, such as JSF implementations and JSF components, used to build web applications utilizing JSF technology.
Terminology
- JSF Implementation: A logical entity to enable web application development with JSF technology. A JSF implementation must conform to the JSF specification ([JSR 127-http://jcp.org/en/jsr/detail?id=127], [JSR 252-http://jcp.org/en/jsr/detail?id=252]).
- JSF Component: A logical entity to enable web application development with JSF technology, possibly outside of what is specified in the JSF specification.
Assumptions
- One (and only one) JSF (versions 1.0, 1.1, or 1.2) compatible implementation is required in a web project to support JSF development.
- Zero, one, or more JSF components that are compatible with the JSF implementation as stated in assumption 1 can be used in a web project to support JSF development beyond specification requirements.
- There is no JSF support offered by the 1.5.x version of the Eclipse Web Tools Platform (WTP) project.
Functions
The following use cases are intended to identify functional requirements to support JSF development in the Eclipse/WTP environment.
The following three functions are required by a web project to enable it for JSF development:
- JSF tags are available to construct JSF JSP pages (i.e. "design-time" support).
- A JSF web project is compiled with JSF JSP pages (i.e. "compile-time" support).
- A JSF web application is deployed and run on a targeted runtime container (i.e. "runtime" support).
Actors
- JSF application developer
- JSF component developer
- JSF tooling value-added reseller (VAR)
Use Cases
1. Actor: JSF application developer
| 1.1 Sharing |
Sharing JSF implementations and components across multiple web projects for JSF development. |
| 1.1.1 | Share JSF implementations and components across multiple web projects in a workspace (define a "JSF Library" once and reference the definition multiple times). |
| 1.2 Enablement | Enabling web projects for JSF development. |
| 1.2.1 | Configure one and only one JSF implementation for a web project to enable building and compiling JSF JSP pages and then running the JSF web application. |
| 1.2.2 | De-configure a JSF implementation from a web project. |
| 1.2.3 | Configure one or more JSF components for a web project to enable building and compiling JSF JSP pages (using components) and then running the JSF web application. Pre-condition: configure one (and only one) JSF implementation for the same web project first (Use Case 1.2.1). |
| 1.2.4 | De-configure one or more JSF components from a web project. |
| 1.2.5 | Configure web project to enable JSF development (for example, modify web application descriptor, add application configuration resource file, etc.) |
| 1.2.6 | Perform additional configuration associated with specific JSF components (for example, configure extension filter in web application descriptor for Tomahawk components, etc.) |
| 1.3 Maintenance |
Respond to changes in referenced, shared JSF implementation and/or component definitions (Use Case 1.1.1). |
| 1.3.1 | Upgrade the referenced JARs in a web project optionally when shared JARs are updated to a newer version. |
| 1.3.2 | Upgrade to newer version of JSF implementation or components optionally when new version is added to the shared location. |
| 1.3.3 | Warn user or remove JSF implementation and/or components from web project when they are removed from the shared location. |
| 1.4 Usability | |
| 1.4.1 | Facilitate viewing JSF implementation and/or components references in web projects (for example, as JARs in one or more classpath containers). |
| 1.4.2 | Filter JSF components that can be referenced by a web project based on the referenced JSF implementation. |
| 1.4.3 | Validate duplicated references of a JSF component. |
| 1.5 Import/Export | |
| 1.5.1 | Facilitate the process to port JSF implementation and components to alternate workspaces, Eclipse installations, or machines (import/export JSF Library Registry). |
| 1.5.2 | Facilitate the process to share web projects with JSF references among alternate workspaces, Eclipse installations, or machines (for example, check out a web project from CVS into any workspace). |
| 1.6 Deployment | |
| 1.6.1 | Configure JARs, JSF implementation, and/or components in a web project for deployment. |
2. Actor: JSF component developer
| 2.1 | Use custom JSF component(s) declaratively to construct and compile JSF JSP pages in a web project. |
| 2.2 | Distribute custom JSF component(s) as extension(s) and provide the same JSF development enablement as in Use Case 2.1. |
3. Actor: JSF tooling value-added reseller (VAR)
| 3.1 | Package sets of JARs as "JSF Libraries" for distribution (for example, using the "jsfLibraries" extension-point). |
| 3.2 | Perform configuration tasks such as in Use Cases 1.6 and 1.7 from an extension. |
| 3.3 | Query the managed state of JSF implementations and components in the location that manages them (for example, in a registry). |
| 3.4 | Query the state of JSF implementation and components referenced by a web project. |
| 3.5 | Enforce the JSF implementation and components provided by extension (Use Case 3.1) as the default configuration (Use Cases 1.2 and 1.4) to enable JSF development (i.e. references are present by default in new web projects).
See: [1] |
| 3.6 | Provide ability to use relative paths to JARs when defining a "JSF Library" (Use Case 1.1) (for example, relative to workspace, relative to plugin, relative to project). |
| Note: | The combination of Use Cases 3.1, 3.5, and 3.6 allows for a pre-configured JSF development environment upon completing required platform and plugin installations. |