I think the biggest problem with using the constructor is that it only gets triggered on the initial view. It's not called if the object is recreated while serialized. That's what you're seeing now. You either need to save-state the initialized data, or you need to provide initialization for both constructors and serialization read methods methods.
I now always use savestate on everything that isn't a managed bean property or an input value-binding. For some beans, I have the last managed property be "initialize" to let me set up some things. These two methods have handled everything I've needed. In the past, I've used Spring and InitializingBean interface on my page bean. I've also used readObject(java.io.ObjectInputStream in) / readResolve() at times in the past. On 3/27/07, Joe Reger, Jr. <[EMAIL PROTECTED]> wrote:
Hi Mike! Thanks. That definitely works for my initial scenario. But I hadn't considered the scenario of failed form validation on page2. When that happens the creation of the backing bean is out of my control and JSF doesn't give me an easy way to initialize. And for all: I know this isn't a myfaces-specific issue... thanks for the help you can offer. So I'm reading this page: http://www.manning-sandbox.com/message.jspa?messageID=39573 And I see that Kito Mann says "if your bean is request-scoped, all you have to do is load the data in its constructor." Which is how I was doing it a while back. I'd like to continue doing it this way but it violates "bean form" and will make it harder to move to Seam. But how bad is using the constructor for initialization? Does anybody on the list use constructors? Is it an issue for production scaling on multiple servers (say, with Tomcat's session replication)? Thanks to all for the ideas and input. Joe On 3/27/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > Still seems to me like the easiest way to do this is with > > <uicommand action="#{ page.save}"> > <f:setPropertyActionListener target="#{page2.initialize}" > value="anything"/> > <f:setPropertyActionListener target="#{page3.initialize}" > value="whatever"/> > </uicommand> > > > On 3/27/07, Joe Reger, Jr. <[EMAIL PROTECTED]> wrote: > > Ok, so I got this to work by using this code in the first bean: > > SecondBean bean = > > (SecondBean)FacesContext.getCurrentInstance().getApplication().getVariableResolver().resolveVariable(FacesContext.getCurrentInstance(), > > "secondBean"); > > return bean.beginView(); > > > > It successfully initializes the second bean, allowing me to load stuff from > > the database, etc. The problem is that when a field on that second form > > fails validation the JSF framework doesn't re-initialize the bean (or keep > > the values I loaded into it) so the app blows up. The bean is declared to > > the request scope. > > > > So now I'm faced with having to turn off all JSF validation (is that even > > possible?) and manually validating everything so that I can run an > > initialization method first. And that'll likely be a problem because I'll > > overwrite the values set from the form. So the phase listener is looking > > better but there's no way that I'm going to write one for each page in the > > app. XML config, backing bean, xhtml page and phase listener just to create > > a page? This is getting way out of control. > > > > It feels like I'm doing something structurally wrong... like I'm fighting > > the framework... but the demo apps I find out there all do it the same way > > and encounter the same issues as soon as you try to go beyond the basic > > scenario. > > > > I just don't understand how I can give control of my page-level beans to the > > framework and have dynamic page-level functionality that's anything more > > than very basic CRUD. > > > > Joe > > > > > > On 3/22/07, David Delbecq < [EMAIL PROTECTED]> wrote: > > > Mail quite confusing, i try to give partial answers anyway > > > > > > En l'instant précis du 22/03/07 12:33, Joe Reger, Jr. s'exprimait en ces > > > termes: > > > > Hi. > > > > > > > > I'm using MyFaces 1.1.5, Facelets 1.1.12, Java 6 and Tomcat 5.5. > > > > > > > > 1) page1.xhtml with backing bean Page1.java. Page loads properly, > > > > displays a form of some sort. > > > > > > > > 2) User types some info into page1.xhtml and hits "Save" which calls > > > > Page1.save(). > > > > > > > > 3) Page1.save() method returns a String. JSF handles the page > > > > navigation and redirection. > > > > > > > > Problem: I can return "page2", to go to the second page in the flow. > > > > But I need to initialize the backing bean for page2.xhtml which is > > > > called Page2.java. If I simply use a faces-config.xml-defined > > > > navigation rule ("page2") I can't do this initialization... it'll call > > > > the page but won't call any methods to initialize. So page2.xhtml > > > > displays for the user but they don't see the effect of the data they > > > > entered on page1.xhtml . > > > you don't need a backing bean per page, if page1 and page2 share same > > > datas, why not use the same backing bean for both? > > > > > > > > Constraint: Ajax4jsf only seems to work when I have a no-argument > > > > empty constructor, so I can't do backing bean initialization there. > > > no-arguments constructor is indeed part of the definition of the bean > > > concept :). If your bean are session scoped, they must be moreover > > > serializable. A class can only be serializable if it has a no argument > > > constructor. > > > > > > > > Question: In a commandLink I can specify #{page2.myInitMethod } > > > > (Facelets processes the EL and tells JSF where to go) which allows me > > > > to initialize my backing bean and return String "page2" so that the > > > > user gets the page. But I can't do that in step 3) above... the > > > > backing bean can only return a String that's pre-defined in > > > > faces-config.xml. Is there any way to route the browser from a > > > > backing bean to another page while specifying an initialization > > > > method? Assuming I can't return " page2.myInitMethod". > > > Let JSF do the initialization stuff itself based on bean definitions > > > made in faces-config.xml. Btw, you can use managed properties if you > > > want you bean to know about each other. JSF does all this by itself > > > Example (myRequestBean.getOtherBean() will now return a JSF session > > > scoped managed bean): > > > <managed-bean> > > > > > <managed-bean-name>myRequestBean</managed-bean-name> > > > > > > <managed-bean-class> com.company.SomeBean</managed-bean-class> > > > > > <managed-bean-scope>request</managed-bean-scope> > > > <managed-property> > > > > > <property-name>otherBean</property-name> > > > > > > <property-class>com.company.SomeOtherBean</property-class> > > > <value>#{mySessionBean}</value> > > > </managed-property> > > > </managed-bean> > > > <managed-bean> > > > > > <managed-bean-name>mySessionBean</managed-bean-name> > > > > > > <managed-bean-class>com.company.SomeOtherBean</managed-bean-class> > > > > > <managed-bean-scope>session</managed-bean-scope> > > > </managed-bean> > > > > > > Moreover, again, you can make page1.java and page2.java a single bean. > > > Or you can have page1.java have a getter returning page2. In page2.xhtml > > > EL would then look like #{ page1.page2.someProperty } > > > > > > > > Motivation: Slowly moving from a plain MyFaces implementation towards > > > > Seam which requires no-argument empty constructors. Also looking to > > > > get Ajax4Jsf running on multi-screen wizard-like flows. The app > > > > consists of about 50 backing beans and in the past I used java object > > > > constructors to initialize the beans, load stuff from the database, > > > > etc. I'm sure I'm missing some basic page flow design pattern built > > > > into JSF and any help is appreciated. > > > > > > > I think you are stuck thinking you need a managed bean per form/page. A > > > JSF Managed bean is simply a bean that has a life duration (depending on > > > it's scope) and is made available to JSF component using EL expression. > > > The structure of your bean and their relation does not have to be tied > > > to your form. A form can combine several beans or a bean can be used by > > > several forms. Also, only beans you want directly available as EL value > > > need to be JSF managed. Objects returned by a getter of a JSF managed > > > bean do not need to be JSF managed. > > > > Thanks, > > > > > > > > Joe > > > > > > > > > > >
