Hi
2013/2/13 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> 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.
>
Ok, good idea to use <name> element. Now it has sense.
> 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.
>
Ok, in that case we just need to keep in mind how a flow is found if no
flowDocumentId is present, because the specification of getFlow() does
not allow to find a flow without a flowDocumentId (the navigation
algorithm requires it).
Thanks Ed for the clarification.
regards,
Leonardo Uribe
> Ed
>
> --