Hi
2013/2/28 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Tue, 26 Feb 2013 00:18:23 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>
> LU> My suggestion is add a method like this (a better name for the method
> LU> is welcomed):
>
> LU> public List<Flow> getFlowStack(FacesContext context)
>
> LU> or create a class called FlowReference with two properties (flowId,
> LU> flowDocumentId)
> LU> and a method like this:
>
> LU> public List<FlowReference> getFlowStack(FacesContext context)
>
> LU> I like this more because you really want to make FlowReference serializable and
> LU> store it into the session, so the other method requires the conversion between
> LU> a FlowReference and a Flow.
>
> I really didn't want to expose the whole flow stack. Instead, I went
> with a modal solution, which is ok because the modality is contained to
> the current client window, so even though the method is on the singleton
> FlowHandler, the behavior is entirely taken from whatever the
> current flow stack is.
>
Use a modal solution is not going to work, because in GET case, h:link
and h:button
call getNavigationCase() and that method should do the calculation of
the navigation
taking into account the current context but without affect it. I also
don't see how
setResetMode() logic could work, but I'll comment that part in the
Return Node mail.
Maybe we need a new class that encapsulates the current context but only for
calculate the navigation (FlowCalculation? or FlowCalculator?
FlowCalculatorResolver?).
Other solution to fix the GET case could be do not call
getNavigationCase() at all
and create a link using the current viewId + flow parameters.
For example. if a.xhtml is rendered and I want to go into flow1 the
link will be:
http://localhost:8080/mycustomapp/a.xhtml?jftfdi=flowDocument1&jffi=flow1
and in that way the algorithm will knew that the GET comes from view a.xml so
save that viewId, enter the flow and do a redirect to the start node.
Anyway, getNavigationCase() should forcefully be fixed and should work in nested
cases, so or the flow stack is exposed or a class that can be
manipulated without
alter the current context to calculate the next flow node is provided.
regards,
Leonardo Uribe
> LU> Ok, I'll keep an eye on any change related to this part. Thanks Ed for your
> LU> attention in these details.
>
> No, please, thank you. Your scrutiny is very essential.
>
> Ed