You're right, it would be hard to see the entire picture without jumping between parts. My point however is that if I look at an activity I should be able to see where I can go from there without scrolling. There is also value in having navigation rules at the bottom. For example when a Cancel button is pressed on any view within a flow module, the same flow rule might apply. But I expect the more common case to be for each view to have its own navigation rules. Then globally applicable navigation rules can be checked as a fallback option.
Rossen
----- Original Message -----
> From: "Ken Finnigan" <kfinniga_at_redhat.com>
> To: jsr344-experts_at_javaserverfaces-spec-public.java.net
> Sent: Wednesday, 14 March, 2012 3:57:34 PM
> Subject: [jsr344-experts] Re: [jsr344-experts mirror] Re: Re:
> [730-TaskFlows] PROPOSAL
> 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 -----
>
> > > 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
> > > >
> > >
> >
>