RE: Re: ADF Faces processScope problem
Laurie, Thanks very much for replying to my query - I've been pondering this one over the weekend and I thought I had a reason it wouldn't work, but having just reread what you said I think you might be right. I have been wondering about using a phase listener for a while for performing initialization (I'll take a look at Shale too) so I'll give that a go before I chuck the towel in with process scopes and go back to session scopes. It won't be particularly elegant though because I'll have to check which page is being loaded in the phase listener. Oh well, if it works, then that'll be progress. Thanks again for the insight, Jim -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Laurie Harper Sent: 16 February 2006 19:07 To: users@myfaces.apache.org Subject: Re: ADF Faces processScope problem Based on the comment, it would seem that your problem is that you need to do your initialization *earlier* in the phase cycle -- i.e. before the Render Response phase begins. Shale's View Controller feature [1] provides a great solution to this; the init() and prerender() hooks would be the two options you'd want to consider for doing your initialization. If you don't want to use Shale, you could implement the same approach in your own app with a little bit more work. Basically, you'd implement your own phase listener and call your initialization logic in beforePhase(). I don't have a sample code snip to hand, but it's fairly straightforward. L. [1] http://struts.apache.org/struts-shale/features-view-controller.html James Moores wrote: snip // =-=AEW This strategy assumes that the ProcessScopeMap // will be inherited from a prior request, have things // added and removed prior to Render Response *without // the token being requested*, then have the token used // repeatedly during Render Response *without further // mutations*. Both of these assumptions seem very // dubious! snip
RE: ADF Faces processScope problem
Hi James, we're not yet using the process scope facilities of ADF, but intend to do so in the future. Thus, I read you message with high interest. Maybe the following is an alternative. Instead of putting your own stuff in the process scope map, keep a map of yourself somewhere. If there is an ADF-supplied id in the process scope available (I saw they had something like a pageflow id), you can use this is a key in your own map. Like: myMap.put(adfContext.getProcessScope().get(XYZID), myValue) and later myValue =(MyData)myMap.get(adfContext.getProcessScope().get(XYZID)) In this way, you don't rely on altering the process scope map. Just an idea. Frank Felix -Original Message- From: James Moores [mailto:[EMAIL PROTECTED] Sent: Thursday, February 16, 2006 5:39 PM To: MyFaces Discussion Subject: ADF Faces processScope problem Hi, I know that it's probably a bit early to be looking for ADF Faces help here in light of the fact that it's only just joined MyFaces, but I'm getting no joy at all on the Oracle forums and people on this list have been so helpful that I thought it was worth a try: I use the ADF Faces 'Process scope' facility a great deal. Unfortunately I have a significant problem. My backing beans cannot be initialized from the faces-config because their values come from a database. I therefore use a separate backing bean to populate the values (because the beans are reused by different pages). The problem is that this initialization bean isn't naturally referenced on the page, and so it's never created by the framework and the initialization doesn't happen. I've gotten around this by putting in a dummy reference to the bean, that triggers my initialization code either in the constructor or in a dummy 'get' method e.g.: af:outputText value=initializingBean.init ... rest of jsp page... This works fine except that now if I change anything in the process scope during the execution of either the constructor or the get method on my 'initializingBean' then it's added nicely (confirmed by printing out the Map). The problem is by the time an action method (or actionListener) is called, the new values in the Map have dissapeared and the state of the map is reset back to what it was before the call to initializingBean. Looking at the source code for ProcessScopeMap (adf-faces/adf-faces-impl/src/main/java/oracle/adfinternal/view/faces/co ntext/ProcessScopeMap.java) I found a rather worrying comment: // =-=AEW This strategy assumes that the ProcessScopeMap // will be inherited from a prior request, have things // added and removed prior to Render Response *without // the token being requested*, then have the token used // repeatedly during Render Response *without further // mutations*. Both of these assumptions seem very // dubious! Now I'm not sure if theis has anything to do with my problem, but it looks a bit suspect. Unfortunately I don't know enough about the internals of either MyFaces or ADF Faces to *fix* the problem. There seems to be very little documentation about processScope's and many postings on the Oracle forum on the subject have gone unanswered. I know it's an experimental feature, but it's a pretty important one! I've been banging my head against a brick wall with this one for nearly a week now so any light anyone can shed on this or ideas of how I could better do my initialization later in the phase cycle (which I think is the problem) would be greatly appreciated. Thanks in advance, Jim -- Jim Moores
RE: ADF Faces processScope problem
Hi Frank, Thanks for your reply. That's a very interesting idea. Not sure if there is an ADF-supplied id, but I'll look into doing it that way if I can't find another solution. Thanks again, Jim -Original Message- From: Frank Felix Debatin [mailto:[EMAIL PROTECTED] Sent: 16 February 2006 17:07 To: 'MyFaces Discussion' Subject: RE: ADF Faces processScope problem Hi James, we're not yet using the process scope facilities of ADF, but intend to do so in the future. Thus, I read you message with high interest. Maybe the following is an alternative. Instead of putting your own stuff in the process scope map, keep a map of yourself somewhere. If there is an ADF-supplied id in the process scope available (I saw they had something like a pageflow id), you can use this is a key in your own map. Like: myMap.put(adfContext.getProcessScope().get(XYZID), myValue) and later myValue =(MyData)myMap.get(adfContext.getProcessScope().get(XYZID)) In this way, you don't rely on altering the process scope map. Just an idea. Frank Felix
Re: ADF Faces processScope problem
James Moores wrote: Hi, I know that it's probably a bit early to be looking for ADF Faces help here in light of the fact that it's only just joined MyFaces, but I'm getting no joy at all on the Oracle forums and people on this list have been so helpful that I thought it was worth a try: I use the ADF Faces 'Process scope' facility a great deal. Unfortunately I have a significant problem. My backing beans cannot be initialized from the faces-config because their values come from a database. I therefore use a separate backing bean to populate the values (because the beans are reused by different pages). The problem is that this initialization bean isn't naturally referenced on the page, and so it's never created by the framework and the initialization doesn't happen. I've gotten around this by putting in a dummy reference to the bean, that triggers my initialization code either in the constructor or in a dummy 'get' method e.g.: af:outputText value=initializingBean.init ... rest of jsp page... This works fine except that now if I change anything in the process scope during the execution of either the constructor or the get method on my 'initializingBean' then it's added nicely (confirmed by printing out the Map). The problem is by the time an action method (or actionListener) is called, the new values in the Map have dissapeared and the state of the map is reset back to what it was before the call to initializingBean. Looking at the source code for ProcessScopeMap (adf-faces/adf-faces-impl/src/main/java/oracle/adfinternal/view/faces/co ntext/ProcessScopeMap.java) I found a rather worrying comment: // =-=AEW This strategy assumes that the ProcessScopeMap // will be inherited from a prior request, have things // added and removed prior to Render Response *without // the token being requested*, then have the token used // repeatedly during Render Response *without further // mutations*. Both of these assumptions seem very // dubious! Now I'm not sure if theis has anything to do with my problem, but it looks a bit suspect. Unfortunately I don't know enough about the internals of either MyFaces or ADF Faces to *fix* the problem. There seems to be very little documentation about processScope's and many postings on the Oracle forum on the subject have gone unanswered. I know it's an experimental feature, but it's a pretty important one! I've been banging my head against a brick wall with this one for nearly a week now so any light anyone can shed on this or ideas of how I could better do my initialization later in the phase cycle (which I think is the problem) would be greatly appreciated. Based on the comment, it would seem that your problem is that you need to do your initialization *earlier* in the phase cycle -- i.e. before the Render Response phase begins. Shale's View Controller feature [1] provides a great solution to this; the init() and prerender() hooks would be the two options you'd want to consider for doing your initialization. If you don't want to use Shale, you could implement the same approach in your own app with a little bit more work. Basically, you'd implement your own phase listener and call your initialization logic in beforePhase(). I don't have a sample code snip to hand, but it's fairly straightforward. L. [1] http://struts.apache.org/struts-shale/features-view-controller.html
