myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "CONNER, BRENDAN \(SBCSI\)" <bc1...@att.com>
Subject RE: JSF Lifecycle and Design Question
Date Wed, 01 Mar 2006 21:58:19 GMT
If this is *really* your first page, you can do something like:
 
<meta http-equiv="Refresh" content= "0; URL=..."/>
 
that references an "outcome" that leads to a page that does an onload
event that simulates the clicking of a hidden commandLink.  We've done
something similar when we want to display a page that says "Working....
please wait" while executing an action that takes a long time.
 
- Brendan
 
-----Original Message-----
From: CONNER, BRENDAN (SBCSI) 
Sent: Wednesday, March 01, 2006 3:51 PM
To: MyFaces Discussion
Subject: RE: JSF Lifecycle and Design Question



So this is, in effect on your index page?  No login page or anything?
 
- Brendan
 

-----Original Message-----
From: j2ee Developer [mailto:j2eeuser@gmail.com] 
Sent: Wednesday, March 01, 2006 3:44 PM
To: MyFaces Discussion
Subject: Re: JSF Lifecycle and Design Question


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