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
>
>
>
>