Hi
2015-02-12 18:02 GMT-05:00 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Thu, 12 Feb 2015 07:29:39 -0600, manfred riem <manfred.riem_at_oracle.com> said:
>
> MR> Hi Zhijun,
> MR> I respectively disagree here as you are requesting to bleed an
> MR> implementation detail into the API for convenience of the implementation.
>
> MR> Note I do not say your points are not valid, but introduction of a new
> MR> method should NEVER be because of an implementation detail forcing this.
>
> MR> So please go ahead and see what would be necessary to prototype this.
>
> Manfred and I talked about this today and he brought me around to his
> viewpoint. I prototyped a simpler solution based on Zhijun's idea that
> does not require an API change, let's take that portion of the
> discussion over to dev_at_javaserverfaces.java.net. Let's use this thread
> to state the proposed resolution of the spec issue.
>
Is this for JSF 2.3, right? or is this issue a clarification for JSF 2.2? My
concern is have a consistent behavior between jsf implementations.
> I propose to resolve this issue by adding the following text to the
> "Managing Flows" section of FlowHandler:
>
> Because Flow instances are immutable, yet the flow stack is per-user,
> implementations must make allowance for flow scoped data (managed
> beans declared to be FlowScoped and data stored in the Map returned by
> getCurrentFlowScope()) to be fully re-entrant. For example, consider
> an application with two flows, A and B, each with a single FlowScoped
> bean MyBeanA and MyBeanB, respectively. Entry into flow A causes
> MyBeanA to become active. Calling from A into B causes MyBeanB to
> become active. Calling back into A causes a new instance of MyBeanA to
> become active, rather than reactivating the earlier instance of
> MyBeanA.
>
> I'm open to further discussion on this, but if no-one follows up, I'll
> consider it closed.
>
It is possible to use the "precedence" information to decide when to
re-enter into the flow or not.
There are two ways to enter into a flow:
- Use the flow id.
- Use a flow call.
But in my understanding, the flow call is special, because it enforce a
relationship between the parent flow and the child flow. In other words,
if the parent flow is ended, the child flow must be closed too, so the
managed beans bound to the child flow are destroyed too.
If the flow is started because the outcome is a flow id, and then
the flow is invoked again in the same way, the algorithm should
restart the flow.
If the flow is started using a flow call, and then the flow is invoked
again, the algorithm should take care of that case as a new flow.
I think this behavior avoid any changes on the spec, but it is
consistent from developer perspective.
Take a look at these two issues:
http://stackoverflow.com/questions/28470390/how-to-re-enter-the-faces-flow-or-start-another-flow-within-one-flow
http://stackoverflow.com/questions/23093821/how-to-have-several-flows-in-a-menu-of-a-template
In both cases, people want to use Faces Flow to define several flows
and build a menu. In that case, you always enter into each flow using
the flow id, so the flow "restart" is critical to make it work (enter into
the flow, navigate somewhere else, try to reenter into the flow). I
personally consider that problem a Mojarra bug (problably an old
one, I ignore if that was fixed), because from spec perspective this
case should be allowed. Please note the use case described works
in MyFaces (that's why we have found the best to do in some cases
is restart the flow by default).
Just for the record, this has been already discussed somehow in:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2014-01/message/3
regards,
Leonardo Uribe
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 17 days til DevNexus 2015
> | 27 days til JavaLand 2015
> | 37 days til CONFESS 2015