Accessing Request Scoped Bean From DynaView Method

Splash Forums PrettyFaces Users Accessing Request Scoped Bean From DynaView Method

This topic contains 5 replies, has 2 voices, and was last updated by  Christian Kaltepoth 5 years, 5 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #18123

    paulcartmell
    Participant

    Hi there

    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.

    Thanks

    Paul.

    #21921

    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.

    Christian

    #21922

    paulcartmell
    Participant

    Hi Christian

    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.

    Any advice, suggestions, improvements welcome :-)

    Thanks

    Paul.

    #21923

    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?

    #21924

    paulcartmell
    Participant

    Hi Christian

    The problem is outside of anything to do with PrettyFaces; the request scoped bean is managed by JSF.

    I’ve done some testing with the following environments:

    Test One –

    Glassfish 2.1

    JSF 1.2

    PrettyFaces 3.3.2

    Result: Constructor called once, properties set in DynaView method and retrieved ok.

    Test Two –

    Glassfish 3.1

    JSF 2.0

    PrettyFaces 3.3.2

    Result: Constructor called twice, once for DynaView and once when accessed by page – obviously the properties will therefore be null.

    I’ll try and look into the reasons why when I get a moment and post unless you have any idea?

    Thanks

    Paul.

    #21925

    Hmmm. Interesting. No, I’ve no idea what may cause this.

    But it would be great if you could post the result of your debugging if you find some time. It would be interesting to know what’s wrong here.

    Thanks

    Christian

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Comments are closed.