Oops, forgot the easiest. One other simple "initializing" trick to to create an "initialized" property on your bean and have it listed as the last property.
http://mail-archives.apache.org/mod_mbox/myfaces-users/200510.mbox/[EMAIL PROTECTED] On 3/1/06, j2ee Developer <[EMAIL PROTECTED]> wrote: > Appreciate your response. That is very close to the way we have implemented > it here. The only distinction being that the first time page load, in our > scenario does not come from an action event ( commandbutton or commandlink). > It is the first request. So I am confused as to where do I call the load(), > other than the constructor. > I understand that probably Shale or Spring can provide us this > flexibility, but we are not evaluating them right now. Does anyone has any > idea how I could implement this. > > > > On 3/1/06, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: > > > > > > Oh, and don't forget to put the following tag in your JSP that displays > the contents of your data bean: > > > > <t:saveState value="#{myDataBean}"/> > > > > > > - Brendan > > > > > > > > -----Original Message----- > > From: CONNER, BRENDAN (SBCSI) > > > > Sent: Wednesday, March 01, 2006 2:18 PM > > To: MyFaces Discussion > > Subject: RE: JSF Lifecycle and Design Question > > > > > > > > > > > > What we do is something like the following: > > > > public class MyDataBean implements Serializable { > > private String field1; > > private Date field2; > > // define getters and setters > > } > > > > public class MyActionBean implements Serializable { > > public MyDataBean myDataBean; > > // define getter and setter for myDataBean > > public String loadData() { > > ... > > return outcome; > > } > > > > public Stirng saveData() { > > ... > > return outcome; > > } > > ... > > } > > > > And then define the following relationship in faces-config.xml: > > > > <managed-bean> > > <managed-bean-name>myDataBean</managed-bean-name> > > > <managed-bean-classcom.example.MyDataBean</managed-bean-class> > > <managed-bean-scope>request</managed-bean-scope> > > </managed-bean> > > > > <managed-bean> > > <managed-bean-name>myActionBean</managed-bean-name> > > <managed-bean-class> com.example.MyActionBean</managed-bean-class> > > <managed-bean-scope>request</managed-bean-scope> > > <managed-property> > > <property-name>mydataBean</property-name> > > <value>#{myDataBean}</value> > > </managed-property> > > </managed-bean> > > > > Then in the screen that leads up to the screen that displays the initial > value of the bean, your commandButton or commandLink would invoke > #{myActionBean.loadData}. The "save" commandButton would invoke > #{myActionBean.saveData}, whose "success" would just lead to redisplaying > the page. > > > > MyActionBean.loadData() would call the EJB layer to fetch the data and > populate the fields within the object returned by getMyDataBean(). (JSF > makes sure that this object is already instantiated.) > > > > MyActionBean.saveData() would call the EJB layer to update the database > with the contents of the object returned by getMyDataBean(). (JSF populates > this bean with the contents of the request.) After this method return, JSF > automatically populates the HTML fields with the values of this bean. > > > > - Brendan > > > > -----Original Message----- > > From: j2ee Developer [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 01, 2006 1:50 PM > > To: MyFaces Discussion > > Subject: Re: JSF Lifecycle and Design Question > > > > > > Thanks Brendan! Sounds interesting! Can you please explain a little bit > more on how are you seperating data beans from action beans. This is how I > have implemented my backing beans. All data is in a formbean(struts style > formbean), this formbean is a member attribute of my actual backing bean. > The actual backing bean just has the action methods like save, clear, delete > etc. > > Also if I do not call the action methods in the constructor, where do I > call the action method before the screen gets displayed? > > > > > > On 3/1/06, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: > > > > > > > > > Also, you shouldn't have to worry about populating the bean's values > again after the save (unless you're changing them or re-querying the > database), since the beans already have their values. From what I recall > (although it's been awhile since I've worked with Struts), this is one of > the areas in which JSF makes our life a lot easier than with Struts. > > > > > > You may want to use <t:saveState>, though, to make sure your bean values > get passed from one request to another. > > > > > > > > > - Brendan > > > > > > -----Original Message----- > > > From: CONNER, BRENDAN (SBCSI) > > > Sent: Wednesday, March 01, 2006 12:59 PM > > > To: MyFaces Discussion > > > Subject: RE: JSF Lifecycle and Design Question > > > > > > > > > > > > I would advise against doing any kind of action as part of a managed > bean's constructor. In my experience, you want to separate out Action > methods from Managed Bean data. Your action methods should be the only > things accessing the EJBs, etc. So you should have an action method that > gets invoked before the screen is displayed. It goes out and gets the data > and populates the data fields, which then get displayed. Your Save then is > very simple, since JSF automatically populates your bean values (at least on > simple screens). Your "save" method then just has to refer to the bean > values when calling the back end to save the data. > > > > > > In our applications, we make the distinction between Actions and Data > very concrete in that we have Action managed beans that are separate from > Data managed beans. This helps keep the developers on the right track, > although the same thing can be accomplished by having Action methods and > data accessors within the same bean. > > > > > > - Brendan > > > > > > -----Original Message----- > > > From: j2ee Developer [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 01, 2006 12:31 PM > > > To: [email protected] > > > Subject: JSF Lifecycle and Design Question > > > > > > > > > I have JSF lifecycle and design question. I am building a prototype, > porting an existing Struts based application to JSF. The issue I am facing > is I believe related to the JSF lifecycle, I need input from you folks as to > whether what I am doing is the right way. > > > > > > Here is the scenario of my application - > > > > > > I have a page with a form with values populated from the database. The > end user makes changes to the fields, and presses the commandbutton save. > The values are saved to the database and the same page presented again with > the new saved values. > > > > > > Here is how I have implemented it - > > > > > > The constructor of the backing bean makes the call to the model layer ( > eventually EJB's), gets the initial data and displays it to the page. After > user makes the changes, on pressing the commandbutton, the event handler, > makes a call to the modellayer for saving the new data. After the save I > populate the backing bean attributes with the new values, and display the > same page again. All my backing beans are request scope ( and that's how I > want them). I am using Myfaces implementation, and myfaces components. > > > > > > Here is the problem I face - > > > > > > The issue I am facing is that on calling save, or any other event, the > constructor is called again . So eventually it ends up that there are double > calls to the modellayer/database than what is required. > > > > > > Is the way I am populating my backing beans wrong? Or is this the only > way JSF handles things. Any input would be appreciated. > > > > > >
