But then the more stuff you want to save during the partial submit, the more you have to put in session, and you're back where you started, with a big session bean and all of the problems that brings. :(
I did some more investigation. Request beans are recreated but it depends when you do your initialization work, whether you have a problem. If you can do everything in the constructor, you're fine. If you have to wait until after injection, I put it in the getters. Even in request scope, that's fine because the getters are called again when the next view is displayed. The only time you have a problem is when you have a value change listener marked as IMMEDIATE and in that value change listener you rely on bean state. In that case, it's after the bean is created, but before any getters are called, thus, you have undefined state. Unfortunately, I have that situation all over the place because virtually of my value change listeners are immediate to avoid form validations! If these beans were managed by Spring (they're not in my case), I imagine the init-method property would get around this. Spring would guarantee it would be executed before the VCL. Other thoughts? -----Original Message----- From: Dodebier, Paul [mailto:[EMAIL PROTECTED] Sent: Friday, April 06, 2007 3:34 AM To: [email protected] Subject: RE: PPR and request scoping Hi Dan, What you could do is adding managed property to the page bean. That managed property is a session scoped bean (like a business bean). The getters and setters of the page bean just delegate to the session scoped business bean. That will at least lessen the burden of cleaning up session scoped beans. Paul -----Original Message----- From: Chris Gibbons [mailto:[EMAIL PROTECTED] Sent: donderdag 5 april 2007 22:15 To: [email protected] Subject: RE: PPR and request scoping I don't have to do that will all values, usually just with a form submission, I noticed an autosubmit triggers a new bean being created, but the values tend to be persisted into the new bean. I may be way off though I'm still a struggling newbie in the world of Trinidad. It's frustrating, but has some really nice features that don't exist elsewhere. Chris -----Original Message----- From: Daniel Hannum [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 2:00 PM To: [email protected] Subject: RE: PPR and request scoping Good idea. Does seem like a lot of work though. I want the whole page to hang around across auto-submits. If that's the only way, I think I'll have to deal with session, and wish upon a star that someday we may be able to declare a bean scope of "page" in faces-config.xml! (Or I guess have a look at Seam or Spring 2.0.) Are there other options within JSF? -----Original Message----- From: Chris Gibbons [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 3:42 PM To: [email protected] Subject: RE: PPR and request scoping You can put any values that you want to maintain in the pageFlowScope and in your getter for that value, check to see if it exists in pageFlowScope first, and if it does, return that value rather than the initialized value when the bean is created. Chris -----Original Message----- From: Daniel Hannum [mailto:[EMAIL PROTECTED] Sent: Thursday, April 05, 2007 1:43 PM To: [email protected] Subject: PPR and request scoping Hi, It would appear that if an autoSubmit/PPR happens on a page, any request-scoped backing beans are recreated. I guess that makes sense... the extra submit is an extra request. First, am I correct? Second, does that mean that every bean backing a page that uses autoSubmit (I use it a lot) needs to be session scope? That brings its own problems. Perhaps there is another option? I even saw Oracle documentation saying that "page backing beans are usually request scope", but alas, they cannot be! Any help is appreciated. Dan
