>>>>> On Tue, 12 Feb 2013 10:06:47 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
LU> Hi
LU> Checking in deep the latest spec snapshot, I have noticed some problems related
LU> to how flow documentId and flow id works. The problem can be seen only when you
LU> start to join all pieces of the puzzle.
LU> First let's put the pieces on the table:
Ahh, you have hit on something that is on my plate to put in the spec,
but it is in the implementation.
LU> <h:commandButton ... action="flow1"/>
LU> This is ok. But note that this suggest in a implicit way that the
LU> flowId must be unique in the entire application, so two different
LU> flows cannot share the same flowId, otherwise the navigation
LU> algorithm cannot decide which route should be taken.
When calling a flow from another flow, the <flow-call> node has an
element for the definingDocumentId. The other case is the case for
getting *into* a flow from not being in one.
This is what I have implemented and what I propose:
modify the spec for the default ActionListener to ask the ActionSource
component for an attribute called, "toFlowDocumentId". If present, use
it as the value of toFlowDocumentId in the newly added
handleNavigation() method on NavigationHandler that takes the additional
argument for toFlowDocumentId. Otherwise call the original
handleNavigation() method. I'll document this on all the standard
ActionSource components, as well as in the spec for the default
ActionListener.
Another aspect I wanted to bring to your attention is the use of the
existing <name> element in the faces-config to be the place where the
flowDefiningDocumentId is declared. If there is no <name> element, the
system takes the flowDefiningDocumentId to be the empty string.
LU> The second part suggest to find a flow you need the documentId and
LU> the id of the Flow, but doesn't suggest the first part that it is
LU> only necessary the flow id?. Look the throws clausule which says
LU> "... NullPointerException - if any of the parameters are null ...".
LU> How a documentId should looks like? The third part try to clarify this concept
LU> but the point is the structure of documentId should be clarified if the
LU> concept is valid. Which is the flow documentId if the flow is defined in
LU> WEB-INF/faces-config.xml, or inside a jar file?
LU> In conclusion, to be honest, in my opinion, the concept behind flow
LU> documentId does not have any sense. Just a flow id is more than
LU> enough. After all, the logic of a flow doesn't require the
LU> documentId, why just don't remove it? Sometimes less is more.
When you start allowing flows to be packaged in jars, having collisions
is more and more likely. I wanted to design the flowDocumentId to be
unobtrusive if no-one is using it, but there if you needed it. I think
most of the time people will be able to get by without it, but there
will be times when it is necessary.
Ed
--