incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Hannum" <>
Subject RE: PPR and request scoping
Date Fri, 06 Apr 2007 20:33:16 GMT
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

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 [] 
Sent: Friday, April 06, 2007 3:34 AM
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


-----Original Message-----
From: Chris Gibbons []
Sent: donderdag 5 april 2007 22:15
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


-----Original Message-----
From: Daniel Hannum [] 
Sent: Thursday, April 05, 2007 2:00 PM
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 [] 
Sent: Thursday, April 05, 2007 3:42 PM
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.


-----Original Message-----
From: Daniel Hannum [] 
Sent: Thursday, April 05, 2007 1:43 PM
Subject: PPR and request scoping



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.



View raw message