Hello Ed,
I was waiting for a proposal of this feature for a long time. I'm really glad to read it today and it looks really fine even it does not answer to my numerous questions.
1) Flow Structure
" This feature intends to provide support for encapsulating related views together such that applications can be created as composites of modules of functionality ". Yes, that is very cool but could we know how. Using this layout ?
-myflow
. -resources (css,images,js,composite components)
-views
-beans
-flow.xml
2) Business logic
Can we use in a standard way a scripting language like Groovy to write our managed beans and store them in the beans folder. In this case, a flow would be very easy to customize once it is shared. if not, will the business logic be packaged in a jar and stored in the web-inf directory? if so, can we say that a flow is not yet well-encapsulated?
3) TaskFlows_FlowOfFlows
I'm against this feature. You should drop it like the concept of sub-templates for 971-MultiTemplating. Too earlier and too recursive for me. Let's keep it simple while we are waiting for a clear vision and for a return of experience.
4) 730-TaskFlow_PrettyURLs
As you may know, I'm currently building a pluggable JSF 2.2 app management with 730-TaskFlows and anyone can contribute to it by developing back-end modules for managing templates, users, modules, views.... So to make things pretty, could you let us bind a Taskflow to a particular path like a JAX-RS controller?
@path("/admin/templates")
public class TemplateService {
}
<flow path="/admin/templates">
</flow>
<flow path="/admin/users">
</flow>
<flow path="/admin/modules">
</flow>
<flow path="/admin/views">
</flow>
And having this feature, It will be very easy for me to filter at runtime the modules in order to create dynamically the menu of my administration console. Note that it can only display the modules that are mapped to a path starting with /admin/
-
http://www.flickr.com/photos/laminba2003/6539835657/in/photostream/lightbox/
4) Flow Metadata
Like for 971-MultiTemplating, I have the project of a Cloud Service where developers can share modules. Could also a flow have this metadata so that we can display its details in the UI like for in my app:
-
http://www.flickr.com/photos/laminba2003/6549426863/in/photostream/lightbox/
<flow path="/admin/templates">
<name>TemplateManager</name>
<version>1.0</version>
<creationDate>2010-11-11</creationDate>
<author>Mamadou Lamine Ba</author>
<authorEmail>laminba2003_at_yahoo.fr</authorEmail>
<authorUrl>
http://www.java.net/blog/120355</authorUrl>
<license>GPL</license>
<copyright>lamine:creations</copyright>
<description>Template Management System</description>
</flow>
Thanks
Lamine
________________________________
De : "edward.burns_at_oracle.com" <edward.burns_at_oracle.com>
À : jsr344-experts_at_javaserverfaces-spec-public.java.net
Envoyé le : Mardi 20 Décembre 2011 22h51
Objet : [jsr344-experts mirror] [jsr344-experts] [TaskFlows-730] Requiremetns Document
Hello Experts,
I've been talking to Gerhard Petracek on IRC and he is keeping me up to
date on an emerging proposal for WindowId-949. That issue does impact
our work on TaskFlows-730, but I can still share the requirements
document for the feature.
This document is being kept in svn and http [1] but I am pasting it
here for your convenience.
ACTION: Please share your comments by 11 January 2012,
Version 20111220
The view (or page) is the most common unit of abstraction in the
current
progamming model for JSF applications. The absence of any formal way to
group related views together leads to web applications that suffer from
the same maintainability and understandability problems as a large
program written as a single programming language function with goto
statements being used to control flow. Specifically, if the smallest
unit you have is the view, then applications quickly become a difficult
to maintain collection of views and the connections between them. This
feature intends to provide support for encapsulating related views
together such that applications can be created as composites of modules
of functionality, with each module consiting of well defined entry and
exit conditions. This feature is heavily influenced by the design of
ADF
Task Flows in Oracle's Fusion Middleware. Spring Web Flow also
influenced the design.
SECTION: Requirements
730-TaskFlows_FlowDeclarationLanguageSPI
It must be possible to do all the authoring for all of the artifact
related to this feature using pure Java or XML, or even an unknown
FDL. There is precedent for this in SpringWebFlow, where flows can be
declared in XML, in Groovy, or in Java (this last is in SWF3, which was
tabled before completion).
730-TaskFlows_FlowDeclarationLanguageInFacelets
It must be possible to author flows by including metadata in Facelet
pages. This enables the developer to have a choice between
centralizing
their flow data in one place, or having it spread out across many views
in the app.
730-TaskFlows_Visualization
It must be possible for a tool to produce a high fidelity visualization
of the flow in an application, regardless of how the flow is authored.
730-TaskFlows_Modularity
It must be possible to group views together into modules with well
defined entry and exit points.
730-TaskFlows_JarOrExplodedPackaging
It must be possible to package a task flow as a jar file, or as an
exploded directory. In both cases, the system must be able to
automatically discover all information necessary to use the task flow
lazily, once per application initialization, without any additional
configuration being provided to the application. In other words, "drop
in and go". This will make it possible to offer task flows as re-usable
components in a software repository, such as a maven repository.
730-TaskFlows_DesignTimeFlowValidation
Whatever way the flow is declared, it must be possible to validate the
correctness and validity of a flow at design time and at run
time. Consider the analogy of a puzzle piece. On its own, a puzzle
piece
may be a valid puzzle piece, but it is only valid for inclusion in one
specific puzzle.
730-TaskFlows_FlowOfFlows
It must be possible to compose a flow as a flow of self contained inner
flows.
730-TaskFlows_CohesiveWithJSF
While other flow technologies strive to be agnostic to a particular
view
technology, JSF Task Flows will specifically be designed for JSF. It is
not a requirement to be view technology agnostic.
730-TaskFlows_PortletSupport
Task Flows must be 100% usable inside of portlets.
730-TaskFlow_Scope
There must be an easy-to-use scope concept that is bound to the task
flow. The metadata for a task flow must include what managed beans are
involved in the task flow, including managed beans that are declared
only with annotations. Any managed beans defined in a scope must be
visible only to views in that scope. This is so two different flows
can
both define a bean named 'foo' and get their own definition at runtime
without colliding with another flow.
730-TaskFlow_Access_CSRF
The task flow access feature must play well with our CSRF protection
feature.
730-TaskFlow_PrettyURLs
It must be possible to make it so when a task flow is traversed, the
URLs in the browser make sense for Search Engine Optimization and
aesthetic purposes.
730-TaskFlow_MultipleWindowResilience
The task flow feature must function properly even when there are
multiple browser windows open on the views of a task flow, each at
different stages of the task flow.
730-TaskFlow_InitializerFinalizer
The task flow must have a way to define via EL a method (with
parameters) to be executed when the flow is entered and exited.
SECTION: Non-requirements
730-TaskFlow_Templates
ADF has a task flow template feature. This is out of scope for this
release.
730-TaskFlow_RegionsFragments
ADF has a region/fragment concept. This is out of scope for this
release.
SECTION: Artifacts
Task Flow
This is the fundamental artifact for the feature. A Task Flow enables
navigation, encapsulation, reuse, and managed bean lifecycles within
a
JSF application.Instead of representing an application as a
collection
of Faces Views, related Views can be grouped into a collection of
reusuable Task Flows. Each Task Flow contains a portion of the
application's flow of control graph. The nodes in the Task Flow are
called activities. The edges between the nodes are called control
flow
cases. A special case of a Task Flow is a "Bounded Task Flow". This
variant has all the properties of a Task Flow but adds the ability to
declare a start node and zero or more exit nodes.
Flow Node
A Task Flow is composed of a number of Flow Nodes, of which several
types are defined.
View
This is just a JSF page
Method Call
An arbitrary method call, specified via EL. This includes the use
of paremeters.
Navigation Rule Set
This is an instance a group <navigation-rule>s that have been in
JSF
since the beginning.
Task Flow Call
Declares that this Task Flow is calling another Task Flow.
Control Flow Rule
A Control Flow Rule declares how one Flow Node relates to another
Flow Node. Note that this concept may not be necessary when using a
FDL that supports programmatic logic, such as Java.
Input Parameter
An Input Parameter only makes sense on a Bounded Task Flow, and
declares a value necessary to the operation of the Bounded Task
Flow
Output Parameter
An Output Parameter is a declared name=value pair that will exist
when a flow is exited.
Flow Scope
The Flow Scope is a CDI custom scope that is associated with a
specific task flow and only exists while the user's session is
navigating within that flow.
ADF View Activity
Is there ever a case where you want to collect the attributes from a
single View Activity instance, and associate them with a collection
of
views, rather than just a single view?
In other words is there always a 1:1 mapping between View Activity
and
view? I'm wondering if the view activity can be specified within the
<f:metadata> section for a page.
Router Activity
The conditional navigation in JSF 2 lets you accomplish a similar
thing.
Method-Call Activity
Invokes application logic via an EL expression. May generate a fixed
outcome or use a method return value.
Scopes
PageFlowScope
ViewScope
FaceletScope (maybe call it ViewFragmentScope?)
Need a way to have managed bean definitions be scoped within a task
flow.
[1]
http://jsf-spec.java.net/nonav/proposals/JAVASERVERFACES_SPEC_PUBLIC-73
0/proposal.txt