Ed> ACTION: Experts, please follow the review instructions in this paragraph
Ed> and followup to this email with your feedback.
Looking at bounded-task-flow, all three views contain a <j:faces-flow-definition/> (note the absence of an id) and it isn't immediately clear to me what makes them part of the same flow definition. Is it because they're co-located in the same folder? Or is it because of the order in which they're navigated?
More generally it's not entirely obvious where the flow starts and where it ends. For example if navigate from bounded-task-flow.xhtml to a view in another folder (which has <j:faces-flow-definition/>) should I expect that view to participate in the current flow or should I expect the current flow to end and a new one to start? Similarly if I navigate directly to next_a.xhtml from index.html, bypassing bounded-task-flow.xhtml, should that start a flow?
The idea seems to be that the flow gets gradually defined as one navigates around. Is that accurate? If so I find it breaks the stated goal of encapsulation since a flow is defined in multiple views and each view could be navigated to from other flow definitions as well. I expect it would be hard to reason about flow navigation in a more realistic application.
FlowHandler states there are two means of defining flows: within VDL pages and in the Application Configuration Resources. I can't see how the stated goal of flow definition encapsulation can be met with the first option and I'm surprised it was the first one to be implemented. Furthermore, I think of a flow definition as a controller, one that includes all navigation and state management needs of the flow. Hence mixing flow definition with the view means no separation of concerns.
It would be useful to hear a little more on what the second option for defining flows will be, faces-config or would each flow definition be self-contained?
Regards,
Rossen