Hi
Checking in deep the latest spec snapshot, I have noticed some problems related
to how flow documentId and flow id works. The problem can be seen only when you
start to join all pieces of the puzzle.
First let's put the pieces on the table:
1. JSF 2.2 spec section 7.4.2 :
- "... When outside of a flow, view identifier has the additional possibility
of being a flow id. ..."
- "... When inside a flow, a view identifier has the additional possibility of
being the id of any node within the current flow or the id of another flow..."
2. javadoc of javax.faces.flow.FlowHandler :
public abstract Flow getFlow(FacesContext context,
java.lang.String definingDocumentId,
java.lang.String id)
Return the Flow whose id is equivalent to the argument id, within the scope
of the argument definingDocument.
Parameters:
context - the FacesContext for the current request.
definingDocumentId - An application unique identifier for the document
in which the returned flow is defined.
id - the id of a Flow, unique within the scope of the definingDocument.
Throws:
java.lang.NullPointerException - if any of the parameters are null
3. JSF 2.2 spec section 7.4.2.1 / 7.4.2.2
"... If the node is a FlowCallNode, save it aside as facesFlowCallNode. Let
flowId be the value of its calledFlowId property and flowDocumentId be the
value of its calledFlowDocumentId property. If no flowDocumentId exists for
the node, let it be the string resulting from flowId + "/" + flowId + ".xhtml".
Ask the FlowHandler for a Flow for this flowId, flowDocumentId pair. Obtain
a reference to the start node and execute this algorithm again, on that start
node. ..."
The first part says that you can use the flowId as if it was a view identifier
in the navigation step. So, if you want to enter to a flow from one page, you
can do something like this:
<h:commandButton ... action="flow1"/>
This is ok. But note that this suggest in a implicit way that the flowId must
be unique in the entire application, so two different flows cannot share the
same flowId, otherwise the navigation algorithm cannot decide which route
should be taken.
The second part suggest to find a flow you need the documentId and the id of
the Flow, but doesn't suggest the first part that it is only necessary the
flow id?. Look the throws clausule which says "... NullPointerException - if
any of the parameters are null ...".
How a documentId should looks like? The third part try to clarify this concept
but the point is the structure of documentId should be clarified if the
concept is valid. Which is the flow documentId if the flow is defined in
WEB-INF/faces-config.xml, or inside a jar file?
In conclusion, to be honest, in my opinion, the concept behind flow documentId
does not have any sense. Just a flow id is more than enough. After all, the
logic of a flow doesn't require the documentId, why just don't remove it?
Sometimes less is more.
regards,
Leonardo Uribe