The way that the request-scoped beans work is they are retained throughout an entire request, so if the request-scoped bean pulls some DB data inside its constructor, then that DB call will be made every time that request-scoped bean is constructed (once per request).
The <f:param /> tag would not be ideal for this because you would need to convert the value from a String to whatever Object type you're working with. <f:param /> only takes Strings as values, I think.
On 4/14/05, Brandon Goodin <[EMAIL PROTECTED]> wrote:
The f:param is an attractive feature. But, considering the value of
the UIData list is maintained for me regardless of anything i do. The
rowData works absolutely fine and is much preferred over the other
solutions that i've seen in this thread. I was able to avoid the
mulitple database hits. I did not fully understand the nature of
request scoped managed beans. It' pretty darn impressive that they
maintain their state without me having to refresh it from the database
or perform a lookup on the single object. JSF is growing on me. I
still think the fact that you can't easily map a url with parameters
to an action sucks along with the bookmarking dilemna. But, i think i
can live with that for now.
Please see my email to Neal Haggard regarding my final solution.
Thanks,
Brandon
On 4/14/05, Srikanth Madarapu <[EMAIL PROTECTED] > wrote:
> Can you pass the id of the selected object using the <f:param>. I have never used the params but sounds like you can do that.
>
> As Heath posted in the mail sith subject "predifined form values"...
> FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get("paramName");
>
> -Srikanth
>
>
> On 4/13/05, Brandon Goodin < [EMAIL PROTECTED]> wrote:
> > This rowData works okay, if you are using session... but there are
> > problems with this. Most of the time you want to query based on the ID
> > of your object. Not the index of the object location. If you database
> > changes behind the scenes and you query a list from the database, the
> > index may produce a different object. The important thing to me is to
> > get the ID for the query. I don't like to keep lists of objects in
> > session. That's weighty and pointless. I appreciate the previous
> > contributions. I'm going to try them out later this evening.
> >
> > Please correct me if i'm wrong.
> >
> > Thanks,
> > Brandon
> >
> > On 4/13/05, Srikanth Madarapu <[EMAIL PROTECTED]> wrote:
> > > In your backing bean, you must have access to the model (of your table ), just call yourModel.getRowData() to get the current row's data or yourModel.getRowIndex to the currenty row's index.
> > >
> > > -----Original Message-----
> > > From: Ray Clark [mailto: [EMAIL PROTECTED]]
> > > Sent: Wednesday, April 06, 2005 10:46 PM
> > > To: [email protected]
> > > Subject: dataTable and commandButton question
> > >
> > > I'm sure this must have been asked before but I can't
> > > find it in the archives. So please forgive me if it
> > > has been asked before.
> > >
> > > I have a dataTable with a commandButton rendered on
> > > each row. When the commandButton is pressed I need
> > > it's managed bean method to know which row the button
> > > was pressed for. So how can the method know which row
> > > to process?
> > >
> > > Thanks,
> > > Ray
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Take Yahoo! Mail with you! Get it on your mobile phone.
> > > http://mobile.yahoo.com/maildemo
> > >
> >
>
--
-Heath Borders-Wing
[EMAIL PROTECTED]
