>>>>> On Tue, 8 May 2012 15:51:02 -0700 (PDT), Rossen Stoyanchev <rstoyanchev_at_vmware.com> said:
Ed> ACTION: Experts, please follow the review instructions in this paragraph
Ed> and followup to this email with your feedback.
RS> Looking at bounded-task-flow, all three views contain a
RS> <j:faces-flow-definition/> (note the absence of an id) and it isn't
RS> immediately clear to me what makes them part of the same flow
RS> definition. Is it because they're co-located in the same folder? Or is
RS> it because of the order in which they're navigated?
Co-located. I'm working on the text for this in the PDF now. The next
Public Review Draft Release Candidate (PRD RC3) will have this clarified
(in section 11.4.3.2 in the latest frame doc).
RS> More generally it's not entirely obvious where the flow starts and where
RS> it ends. For example if navigate from bounded-task-flow.xhtml to a view
RS> in another folder (which has <j:faces-flow-definition/>) should I expect
RS> that view to participate in the current flow or should I expect the
RS> current flow to end and a new one to start? Similarly if I navigate
RS> directly to next_a.xhtml from index.html, bypassing
RS> bounded-task-flow.xhtml, should that start a flow?
I have clarified these requirements in the PDF.
RS> The idea seems to be that the flow gets gradually defined as one
RS> navigates around. Is that accurate? If so I find it breaks the stated
RS> goal of encapsulation since a flow is defined in multiple views and each
RS> view could be navigated to from other flow definitions as well. I expect
RS> it would be hard to reason about flow navigation in a more realistic
RS> application.
That "gradual definition" business is a hold-over from an earlier idea
in the spec that has since been proven to be untenable, for the reasons
you suggest. I've taken it out.
RS> FlowHandler states there are two means of defining flows: within VDL
RS> pages and in the Application Configuration Resources. I can't see how
RS> the stated goal of flow definition encapsulation can be met with the
RS> first option and I'm surprised it was the first one to be
RS> implemented. Furthermore, I think of a flow definition as a controller,
RS> one that includes all navigation and state management needs of the
RS> flow. Hence mixing flow definition with the view means no separation of
RS> concerns.
Right, I've taken that out. Now the way to define a flow is either in
the application configuration resources, or with a bean annotated with @FlowDefinition.
RS> It would be useful to hear a little more on what the second option for
RS> defining flows will be, faces-config or would each flow definition be
RS> self-contained?
These are great questions. I would appreciate your close scrutiny of
the new text in the upcoming PRD RC3.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/