From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 13 Mar 2012 17:18:07 +0100

I personally find the word "TaskFlow" a bit irritating, as the term is
mostly used by the Planning and ALM domain.

Is it used already, I noticed, in the XML sample it was, or from
contributing systems like ADF, Spring, etc.?

Action may be a little old fashioned or from a Swing and Struts era, but
even terms like "Activity" might sound a bit better.

Just my impression, maybe I deal with Agile Coaching, PM and Task Planning
too much?[?]

Other than the exact wording for particular elements I find it very
attractive. We applied a State Engine (thus the main term used there were
State and Transition) based Flow API under an Eclipse RCP environment some
while ago for a major telco. I still believe, something like it would suit
Eclipse well, but aside from the actual UI toolkit, there are aspects of it
I see useful here, too.

Werner

On Tue, Mar 13, 2012 at 4:53 PM, David Schneider <david.schneider_at_oracle.com
> wrote:

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