Hi Here some answers:
LP>> In fact, I could trigger flow transitions only using a h:link for now. LP>> LP>> So neither LP>> * <p:menuitem value="Let's test" outcome="flow1" /> in a PF p:menubar LP>> * <p:commandButton value="Let's test 2" action="flow1" /> LP>> * <h:commandButton value="Let's test 3" action="flow1" /> LP>> * <h:commandButton value="Let's test 4" action="/flow1" /> LP>> * <h:commandButton value="Let's test 5" action="/flow1/flow1" /> LP>> * a direct transition to /flow1/flow1.xhtml (by typing the URL in the brower url bar) LP>> LP>> work. LP>> LP>> But LP>> * <h:link outcome="flow1">Test 6</h:link> LP>> * <h:link outcome="/flow1/flow1.xhtml">T LP>> est 7</h:link> LP>> LP>> do "work". LP>> LP>> By working, I mean that the FlowHandler.FLOW_ID_REQUEST_PARAM_NAME LP>> (jffi) is defined, a transition is detected and FlowHandlerImpl processes it. It is ok. h:link triggers a GET request, so the request parameter is added. In the other cases, the transition is done when NavigationHandler.handleNavigation(...) is processed. p:menuitem don't implement the new spec related to calculate the outcome in case of a flow (check not null on navigationCase.getToFlowDocumentId() and add the request parameters). One partial solution could be add the required request parameter manually. LP>> When I try to use an empty flow1-flow.xml, or to use a flow1-flow.xml such as ... LP>> there is a problem at the outcome computation step. There is a small bug when an empty flow is used, which was already fixed on: https://issues.apache.org/jira/browse/MYFACES-3845 In the xml you need to define the start node. But looking JSF 2.2 section 11.4.3.3 it says: "... The following conventions apply to flows defined in this manner. Any flow definition in the corresponding -flow.xml file will override any of the conventions in the case of a conflict - Every vdl file in that directory is a view node of that flow. - The start node of the flow is the view whose name is the same as the name of the flow. - Navigation among any of the views in the directory is considered to be within the flow. - The flow defining document id is the empty string. ..." Checking the code it seems the conditions has been applied but only when the empty flow is provided. It is a bug. Please create an issue under jira and I'll fix it. LP>> there is a first transition from <no flow> (being on /accueil.xhtml) to "flow1" LP>> (going to /flow1/flow1.xhtml). flow1 is correctly stacked at this step. LP>> But then, another transition from /flow1/flow1.xhtml to /flow1/flow1.xhtml LP>> is immediatly triggered by an automatically generated (I think) navigation case. LP>> During this transition, flow1 is popped from stack and a null pointer exception occurs. This is an edge case. Theorically it should work. Could you please provide the stack trace, so I can investigate it further?. regards, Leonardo 2014-02-12 11:44 GMT-05:00 Kito Mann <[email protected]>: > Thanks for the info, Karl. Good to know. > > On Wednesday, February 12, 2014, Karl Kildén <[email protected]> wrote: > >> This question has been raised on the mailing list several times. The answer >> is always the same: >> Released functionality is mature and stable. 0.X indicates that the API >> might change but so far this has happened like 1-2 times I think and >> probably took 2 minutes to fix for depending projects. The actual impl is >> stable though. >> >> By following the discussion on the mailing list it's quite clear that they >> put effort into not only porting CODI but to enhance it as well. I have >> Deltaspike in production for many, many months with no issues (all though >> not 0.6-SNAPSHOT). And you can assume it's going to be more tested then >> code you include yourself to do something similar. >> >> The parts regarding JSF is stable for 0.6 so getting the support from a >> SNAPSHOT right now and replace with stable release later is not a very >> adventurous. >> >> These are the docs for getting started: >> http://deltaspike.apache.org/jsf.html >> >> cheers >> >> >> On 12 February 2014 11:33, Howard W. Smith, Jr. >> <[email protected]<javascript:;> >> >wrote: >> >> > On Feb 12, 2014 1:40 AM, "Karl Kildén" <[email protected]> wrote: >> > > >> > > Deltaspike modules have consistently been usable off the shelf and >> would >> > be >> > > a far better solution then doing tricks to make CODI work. >> > >> > +1 >> > >> > > >> > > However using JSF stuff would require you to use 0.6-SNAPSHOT. I would >> > > actually just use @SessionScoped, write a TODO and wait for 0.6 release >> > if >> > > I could. Otherwise I would use SNAPSHOT since the JSF stuff is all >> fixed >> > > for 0.6 afaik. >> > >> > When I experimented with CODI, I used 1.0.6 snapshot and had the same >> thing >> > in mind and then i heard that CODI was dead project, and most likely >> 1.0.6 >> > would not be released. And I did hear and recognize that deltaspike is >> > recommended instead of CODI. Someone, please confirm. >> > >> > > >> > > >> > > On 12 February 2014 02:44, Kito Mann <[email protected]> wrote: >> > > >> > > > How mature is DeltaSpike? It's only at 0.05. >> > >> > +1 good question. >> > >> > > > >> > > > On Tuesday, February 11, 2014, Thomas Andraschko < >> > > > [email protected]> wrote: >> > > > >> > > > > Can't you just switch to DS? >> > > > > >> > > > > >> > > > > 2014-02-11 18:46 GMT+01:00 Leonardo Uribe <[email protected] >> > <javascript:;> >> > > > > >: >> > > > > >> > > > > > Hi >> > > > > > >> > > > > > CDI implementations does not require to provide anything to JSF >> in >> > > > > > order to make @FlowScoped to work. The code has been tested >> against >> > > > > > OWB and Weld and it works in both cases. >> > > > > > >> > > > > > But the flow stuff relies on the new ClientWindow API, and that >> > could >> > > > > > cause a conflict with CODI, because CODI provides a solution for >> > this >> > > > > > part too. In fact, the solution introduced in the standard comes >> > from >> > > > > > CODI. >> > > > > > >> > > > > > In your particular case, the best option is provide a custom >> > > > > > ClientWindowFactory / ClientWindow that implements >> > > > > > ClientWindow.getId() method and grab the value generated by CODI. >> > > > > > Theorically there is no need of the custom PhaseListener, because >> > the >> > > > > > "attachWindow" step is done in CODI. I haven't tried it but I >> > suppose >> > > > > > a custom ClientWindow will work. >> > > > > > >> > > > > > regards, >> > > > > > >> > > > > > Leonardo Uribe >> > > > > > >> > > > > > 2014-02-11 11:56 GMT-05:00 [email protected] <[email protected]>: >> > > > > > > On 11/02/2014 14:51, [email protected] wrote: >> > > > > > >> >> > > > > > >> On 11/02/2014 10:28, [email protected] wrote: >> > > > > > >>> >> > > > > > >>> On 11/02/2014 03:30, Leonardo Uribe wrote: >> > > > > > >> >> > > > > > >> >> > > > > > >> [...] >> > > > > > >>>> >> > > > > > >>>> @FlowScoped annotation is for CDI only, so it will not work >> > for >> > > > JSF >> > > > > > >>>> managed beans. In your case, I believe the bean is >> > instantiated >> > > > but >> > > > > it >> > > > > > >>>> is not stored in any context, so once is created is >> discarded, >> > > > > giving >> > > > > > >>>> the impression that the bean is working but it is not. >> > > > > > >>>> >> > > > > > >> > > > > -- > ___ > > Kito D. Mann | @kito99 | Author, JSF in Action > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting > http://www.JSFCentral.com | @jsfcentral > +1 203-998-0403 > > * Listen to the Enterprise Java Newscast: *http://w > <http://blogs.jsfcentral.com/JSFNewscast/>ww.enterprisejavanews.com > <http://ww.enterprisejavanews.com>* > * JSFCentral Interviews Podcast: > http://www.jsfcentral.com/resources/jsfcentralpodcasts/ > * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17
