>>>>> On Tue, 13 Mar 2012 09:53:18 -0600, David Schneider <david.schneider_at_oracle.com> said:
DS> This flow is used to create/edit some type of data record (e.g. a
DS> customer contact, employee, etc.). The flow's starting point, its
DS> 'default activity', is indicated with the green halo.
Obviously the router is an embodiment of some logic. How is the logic
encoded? A java method invocation? I don't have "Router Activity"
correctly represented in the proposal [1]. David, can you please say
what I should put for "Router Activity"?
RS> David, thanks for the example. It gives me an idea of the origin of
RS> the proposal although I'm unsure whether to treat it as what is
RS> being proposed in terms of discussing it?
David was simply sharing what's in ADF.
RS> One thing that strikes me about the example configuration is how
RS> disconnected the "control flow rules" are from the activities. With
RS> the diagram I can follow the navigation in one place. With the XML I
RS> have to review the flow nodes first and then scroll down to
RS> comprehend the flow. I can imagine in a large flow this becomes hard
RS> to absorb as it's in two places.
DS> That's a good point regarding the control flow rules being disconnected
DS> from the activities. Maybe a better schema would place the control flow
DS> cases as children of the activity element so all the information about
DS> the activity and where the application can flow to following the
DS> activity is all in one place. Like JSF ADF also supports flow
DS> originating from '*' (wildcard) but that can be handled as a special case.
KF> I think the schema could be sliced either way, and which is chosen
KF> determines whether the control flow is in one place or all the data
KF> around an activity and its' flow are in one place. With either
KF> option there is not an easy way to see the entire picture of the
KF> flow without jumping between parts.
RS> You're right, it would be hard to see the entire picture without
RS> jumping between parts. My point however is that if I look at an
RS> activity I should be able to see where I can go from there without
RS> scrolling. There is also value in having navigation rules at the
RS> bottom. For example when a Cancel button is pressed on any view
RS> within a flow module, the same flow rule might apply. But I expect
RS> the more common case to be for each view to have its own navigation
RS> rules. Then globally applicable navigation rules can be checked as a
RS> fallback option.
Rossen, when you say "navigation rules at the bottom" what do you mean?
At the bottom of what? The faces-config.xml segment that deals with a
particular Faces flow? Rossen, can you perhaps suggests some diffs to
the proposal at [1] to clarify what you mean?
KF> One question I had, do we intend for nodes of the flowlet
Faces Flow, that is.
KF> (ie. activities) to be re-usable across different flow definitions?
KF> If yes, then I believe it makes it necessary for the control flow to
KF> be separated from the activity content, as in a different context
KF> the same outcome may not flow to the same activity.
KF> I think it would be beneficial to be able to re-use flow
KF> definitions, and the individual nodes of a flow, but I may be alone
KF> on the latter point.
Here we have a choice between simplicity and configurability. As much
as I'd like to disallow this kind of re-use, I do expect people will
want to be able to do it.
DS> I'm not sure of the value of allowing the nodes (activities) to be
DS> reused across flows. Our experience with ADF is the activity
DS> definition is often context sensitive, such use using a managed bean
DS> only defined in the flow where the activity exists. That makes it
DS> hard to reuse them in a different context.
Ahh, thank you so much for weighing in. I trust your experience in
this regarding what's useful and useless.
DS> One form of activity definition reuse in ADF is the flow template.
DS> You can define a flow template with a number of bean definitions,
DS> activities, etc. and then extend it to create a specific instance
DS> with additional metadata. This has been useful in cases where there
DS> are common flow patterns but each instance has it's own nuance.
David and I talked about this, and I've also talked with Frank Nimphius
who works very extensively with ADF Task Flows in customer contexts and
he indicatedthat flow templates are safe for us to leave for a future
revision, as I've already stated in the proposal. Conclusion: Our
answer to flow reuse is flow templates, and we'll address flow templates
in a future release.
Now that we have ResourceHandler as the one true way to load Facelet
pages, I think it would be very handy to allow all the views in a
resource library to form an implicit flow. What do ya'll think of that?
Ed
[1] Version 20120316 of
http://javaserverfaces-spec-public.java.net/nonav/proposals/JAVASERVERFACES_SPEC_PUBLIC-730/proposal.txt
Please make sure you are looking at a document with "Version 20120316"
at the top. You may have to refresh your browser cache.
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/