Looks like TaskFlows-730 has a dependency on CDI for scoping. Thankfully the kind folks at JBoss have fixed WELD-510 [1]. My goal is to test CDI/Weld in portlets in the February timeframe. If all goes well, then 730-TaskFlows_PortletSupport should be possible.
[1]
https://issues.jboss.org/browse/WELD-510
On Dec 21, 2011, at 2:31 PM, lamine wrote:
>
>
>
> 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