If you use save state to save the whole object it will require you to serialize your whole object which we don't like.
If you use save state to save just the object id you still have a problem because you don't know when to load the object from the database on the second bean (employee details). So I guess there are only 2 solutions left for me: 1. Use session scope second bean (employee details) and initialize it from the first bean (employees list). Or 2. From the first bean - send the object id as a parameter on the request. On the second bean - Load the object on the constructor if the parameter exists on the request. If not do nothing. I'm afraid I can't think of any other solutions :-( -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Wessendorf Sent: Wednesday, April 26, 2006 2:21 PM To: MyFaces Discussion Subject: Re: ManagedBean Get and Set Values on Constructor have you used <t:saveState/> or did I just get you wrong ? On 4/26/06, Uri Kalish <[EMAIL PROTECTED]> wrote: > But only to the first bean connected to the page. We need this data on > the second bean. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Matthias Wessendorf > Sent: Wednesday, April 26, 2006 12:43 PM > To: MyFaces Discussion > Subject: Re: ManagedBean Get and Set Values on Constructor > > well, t:updateActionListener allows you to pass objects, > that's what I have done with it. > > ids are possible at all > > -Matthias > > On 4/26/06, Uri Kalish <[EMAIL PROTECTED]> wrote: > > Thanks for the solution, but... > > If I understand correctly these are all solutions just to make the > > passing of the selected employee id parameter from the table on the > > employees list page to the employees list bean more elegant without > > using java script and hidden field. > > > > Still... > > Case 1. The employee details bean (second bean) will have to get the > id > > from the employees list bean (first bean). > > Case 2. Sometimes we submit the details bean and will arrive to the > same > > page again (some error). > > So the details bean will have to set its values (load the details from > > the database) by the id. Sometimes it will come from another bean > (case > > 1) and sometimes from the same bean (case 2). > > > > If it will try to set the values on its constructor, this can be done > > for case 1 by the facesContext/createValueBinding trick, but for case > 2 > > - we are in trouble because at constructor it's too early (its setters > > hasn't been called yet). > > > > Does this mean that we are forced to set the id on the constructor on > > case 1 and load details ON EACH OF THE DETAILS BEAN GETTERS (i.e. > Check > > if we already loaded the employee object from the database, if not - > > load, set the property value by the object value, return the value)??? > > > > > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of > > Matthias Wessendorf > > Sent: Tuesday, April 25, 2006 7:29 PM > > To: MyFaces Discussion > > Subject: Re: ManagedBean Get and Set Values on Constructor > > > > You also should take a look on UISaveState [2] > > > > [2] http://wiki.apache.org/myfaces/SaveState > > > > On 4/25/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > Hi Uri, > > > > > > you can do all the *ugly* parameter handling, but you should go > ahead > > and use > > > <t:updateActionListener/>. > > > > > > > > > For instance you have a grid like > > > <h:dataTable var="analysemappe" > > > value="#{analysisFolderMaster.analysisfolders}"...> > > > > > > </h:dataTable> > > > > > > You could do something like > > > > > > <h:commandButton > > > value="Details" > > > styleClass="stdButton" > > > action="details"> > > > > > > <t:updateActionListener > > > property="#{analysisFolderDetail.analysisFolder}" > > > value="#{analysemappe}" /> > > > </h:commandButton> > > > > > > > > > > > > This commandButton will navigate you to a *detail* page and passes > the > > > current grid object (#{analysemappe}) to "analysisFolder"-property > of > > > the backing bean "analysisFolderDetail". > > > > > > > > > On the detail page you can do stuff like > > > > > > <h:outputText value="#{analysisFolderDetail.analysisFolder.name}"/> > > > > > > See also [1] for more. Also you could uses Shale's ViewController. > > > > > > -Matthias > > > > > > [1] > > > http://wiki.apache.org/myfaces/ExecutingMethodsFromLinkButtonParameters > > > > > > > > > On 4/25/06, Uri Kalish <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > We have a page displaying a list of objects. > > > > > > > > When a user clicks on an object we want to display and edit the > > object > > > > details on another page. > > > > > > > > > > > > > > > > So... > > > > > > > > A user clicks on an object on page1. > > > > > > > > We save the object id (by java script) to a hidden field on page1 > > (bound to > > > > a field on ManagedBean1) and submit page1. > > > > > > > > On ManagedBean1 code we navigate to page2. > > > > > > > > ManagedBean2 gets the id from the field on ManagedBean1 (by > > facesContext and > > > > createValueBinding) and saves it to a field (bound to a hidden > field > > on > > > > page2). > > > > > > > > It happen ON THE CONSTRUCTOR of ManagedBean2 because it needs the > > object id > > > > in order to initialize its fields from the database. > > > > > > > > > > > > > > > > Now... > > > > > > > > If we now want to refresh page2 (e.g. due to some error)... we > can't > > get the > > > > id on time (because getting the id is done on the ManagedBean2 > > constructor > > > > before it restores its values from the page). > > > > > > > > > > > > > > > > Any ideas regarding best practice for this issue? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > This email has been scanned by the MessageLabs Email Security > > System. > > > > For more information please visit > > > > http://www.messagelabs.com/email > > > > > > ______________________________________________________________________ > > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > Aechterhoek 18 > > > 48282 Emsdetten > > > http://jroller.com/page/mwessendorf > > > mwessendorf-at-gmail-dot-com > > > > > > > > > -- > > Matthias Wessendorf > > Aechterhoek 18 > > 48282 Emsdetten > > http://jroller.com/page/mwessendorf > > mwessendorf-at-gmail-dot-com > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > > -- > Matthias Wessendorf > Aechterhoek 18 > 48282 Emsdetten > http://jroller.com/page/mwessendorf > mwessendorf-at-gmail-dot-com > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > -- Matthias Wessendorf Aechterhoek 18 48282 Emsdetten http://jroller.com/page/mwessendorf mwessendorf-at-gmail-dot-com ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
