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