For initializing data or pre-populating
fields you may want to look into Shale’s abstractviewcontroller and the
added lifecycle methods it gives your JSF backing beans.
-adrian
From: j2ee Developer
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 01, 2006
2: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.
-----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.
-----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.
|