myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <mkien...@gmail.com>
Subject Re: JSF Lifecycle and Design Question
Date Wed, 01 Mar 2006 21:56:36 GMT
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/%3c435FFBA3.7040009@obsidium.com%3e

On 3/1/06, j2ee Developer <j2eeuser@gmail.com> 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) <bc1378@att.com> 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:j2eeuser@gmail.com]
> > 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) <bc1378@att.com> 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:j2eeuser@gmail.com]
> > > Sent: Wednesday, March 01, 2006 12:31 PM
> > > To: users@myfaces.apache.org
> > > 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.
> >
> >
>
>

Mime
View raw message