I'm not sure of the value of allowing the nodes (activities) to be
reused across flows. Our experience with ADF is the activity definition
is often context sensitive, such use using a managed bean only defined
in the flow where the activity exists. That makes it hard to reuse them
in a different context.
One form of activity definition reuse in ADF is the flow template. You
can define a flow template with a number of bean definitions,
activities, etc. and then extend it to create a specific instance with
additional metadata. This has been useful in cases where there are
common flow patterns but each instance has it's own nuance.
Dave
On 3/14/2012 1:57 PM, Ken Finnigan wrote:
> I think the schema could be sliced either way, and which is chosen
> determines whether the control flow is in one place or all the data
> around an activity and its' flow are in one place. With either option
> there is not an easy way to see the entire picture of the flow without
> jumping between parts.
>
> One question I had, do we intend for nodes of the flowlet (ie.
> activities) to be re-usable across different flow definitions? If
> yes, then I believe it makes it necessary for the control flow to be
> separated from the activity content, as in a different context the
> same outcome may not flow to the same activity.
>
> I think it would be beneficial to be able to re-use flow definitions,
> and the individual nodes of a flow, but I may be alone on the latter
> point.
>
> Regards
> Ken Finnigan
>
> ------------------------------------------------------------------------
> *From: *"David Schneider" <david.schneider_at_oracle.com>
> *To: *jsr344-experts_at_javaserverfaces-spec-public.java.net
> *Sent: *Wednesday, March 14, 2012 3:42:30 PM
> *Subject: *[jsr344-experts] Re: [jsr344-experts mirror] Re: Re:
> [730-TaskFlows] PROPOSAL
>
>
> Hi Rossen,
>
> That's a good point regarding the control flow rules being
> disconnected from the activities. Maybe a better schema would place
> the control flow cases as children of the activity element so all the
> information about the activity and where the application can flow to
> following the activity is all in one place. Like JSF ADF also
> supports flow originating from '*' (wildcard) but that can be handled
> as a special case.
>
> Dave
>
> On 03/14/2012 11:29 AM, Rossen Stoyanchev wrote:
>
>
> David, thanks for the example. It gives me an idea of the origin
> of the proposal although I'm unsure whether to treat it as what is
> being proposed in terms of discussing it?
>
> One thing that strikes me about the example configuration is how
> disconnected the "control flow rules" are from the activities.
> With the diagram I can follow the navigation in one place. With
> the XML I have to review the flow nodes first and then scroll down
> to comprehend the flow. I can imagine in a large flow this becomes
> hard to absorb as it's in two places.
>
> Rossen
>
> ------------------------------------------------------------------------
>
> *From: *"David Schneider" <david.schneider_at_oracle.com>
> *To: *jsr344-experts_at_javaserverfaces-spec-public.java.net
> *Sent: *Tuesday, 13 March, 2012 11:53:18 AM
> *Subject: *[jsr344-experts] Re: [jsr344-experts mirror] Re:
> [730-TaskFlows] PROPOSAL
>
>
> Here's an example of an ADF task flow (XML definition with
> descriptive comments attached):
>
> This flow is used to create/edit some type of data record
> (e.g. a customer contact, employee, etc.). The flow's
> starting point, its 'default activity', is indicated with the
> green halo. The router determines if an existing record key
> was passed to the flow as an input parameter and generates
> either outcome 'goto-create' or 'goto-edit'. The record is
> then displayed to the user for editing by the 'edit-record'
> view activity. Once the user is done editing the record the
> flow exits via the 'done' return activity.
>
> Dave
>
> On 03/13/2012 08:35 AM, David Schneider wrote:
>
>
> Hi Rossen,
>
> I'll create an example flow from ADF is send it out. Give
> me a day or so to get it pulled together.
>
> Dave
>
> On 03/12/2012 05:32 PM, Rossen Stoyanchev wrote:
>
> On 03/06/2012 08:27 PM, Edward Burns wrote:
>
> How do you define a flow as an object?
>
> Here are the three most obvious approaches.
>
> 1. additional syntax in the faces-config.
> 2. metadata in the Facelet pages that comprise
> the flow.
> 3. java code
>
> Perhaps there are specific cases that motivate
> including flow information in Facelet pages but I
> can't see what they are. It's worth mentioning them
> explicitly since putting flow information
> (navigation?) in Facelet pages seems contrary to the
> goal of Task Flow encapsulation.
>
> Would it be too early to create a small illustration
> of what a Task Flow might look like? Perhaps as simple
> as 2-3 flow nodes including a view, a method call,
> navigation, some conditional routing. I don't know
> what others think but it would help me get a better idea.
>
> Rossen
>
>
>
>
>
>