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
----- Original Message -----
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
----- Original Message -----
<blockquote>
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:
<blockquote>
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:
<blockquote>
On 03/06/2012 08:27 PM, Edward Burns wrote:
<blockquote>
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
</blockquote>
</blockquote>
</blockquote>
</blockquote>