Should there be any issues with me accessing a request scoped backing bean from within a method call of a DynaView?
Within the DynaView method call, the backing bean is looked up from the FacesContext and parameters set, however when the backing bean is accessed from the returned page of the DynaView the parameters are null.
1) Is the way I am doing this possible?
2) Is there a better way of achieving the same result?
Essentially, I am doing an amount of work in the DynaView method which I could do again in the backing bean but I would rather set the result of the work into the backing bean ready for when the page is accessed.
I not sure if your setup will work. PrettyFaces will forward the request internally after the view determination (dynaview method call). In theory request scoped beans should survive this forward. But this may depend on the concrete container your are using. Do you use CDI, Spring or anything else?
However I think it is rather uncommon to set parameters on foreign beans from a dynaview method. Could you perhaps describe the problem you are trying to solve? Perhaps there is a simpler way to achieve it.
A lot of data retrieval and analysis is done to determine the correct view within the DynaView method, which includes arriving at the display data for the page.
This work can be done again however I was ‘short-circuiting’ and populating the backing bean with the required data for the page.
This was originally coded in an environment with JSF 1.2 and PrettyFaces 3.1.0 (with nothing else) and worked fine. I’m upgrading to JSF 2.0 and PrettyFaces 3.3.2 and this method now presents the problem I’m describing.
I’m happy to put the code into a common helper class and execute from both places (this is how I am now implementing) but would like to understand why this now fails.
I don’t think that we changed anything since 3.1.0 that may cause this behavior to change. But I may be wrong. I don’t know!
Are you sure the request scoped bean is re-created? Perhaps some component explicitly sets the properties to null? You could check this by adding a log output to the default constructor and the property setter.
Is your request scoped bean managed by JSF or some other container like CDI/Spring?