Using
<h:dataTable binding="myBackingBean.myDataTable"
private transient HtmlDataTable myDataTable;
public void setMyDataTable(HtmlDataTable dt) { this.myDataTable= dt;}
public HtmlDataTable getMyDataTable() {return this.myDataTable;}
will set a reference to your data table in your myBackingBean.
Some IDEs (like JDeveloper) will automatically create these bindings
and methods for you.
On 9/9/05, David Haynes <[EMAIL PROTECTED]> wrote:
> How does the bean get access to these values?
>
> Mike Kienenberger wrote:
>
> >There are already "first" and "rows" attributes for dataTable that
> >match your "start" and "number of rows to display" parameters.
> >
> >It's probably just a matter of providing a backing data model that
> >lazy-loads the data. The view layer can (and does) provide an API for
> >specifying what data to load, but your business /backing layer has to
> >provide the mechanism for loading the data.
> >
> >On 9/8/05, David Haynes <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Kevin and Mike:
> >>This comes back to the issue I was raising earlier this week regarding
> >>parameterized dataTables. There are a number of cases where it would be
> >>nice to be able to set some values for use by the backing bean when it
> >>is invoked by the dataTable tag. In this case, being able to specify a
> >>'start' and 'number of rows' value would make the ResultSet more manageable.
> >>
> >>It seems to me that the current dataTable tag has the assumption that
> >>the backing bean will hand it a complete result set and that is what is
> >>to be displayed. This is OK as far as it goes (and from a pure object
> >>perspective, makes sense) but there seems to be a disconnect between the
> >>handling of large result sets and this model. The disconnect comes from
> >>our desire not to consume so much system resource. The fact that there
> >>is no way to limit the size of the result set other than in a static
> >>manner - that is, the limits to the result sets are hard-coded in the
> >>backing bean - severely restricts how dataTable may be used.
> >>
> >>At a minimum, it would be nice to have parameters for start and number
> >>of rows that could be set for the dataTable. In a larger sense, it would
> >>be nice to be able to specify any set of name/value pairs that the
> >>backing bean could then use as it saw fit. You could even have a new
> >>dataTable type, say dynamicDataTable, to address this if it made more sense.
> >>
> >>-david-
> >>
> >>Kevin Galligan wrote:
> >>
> >>
> >>
> >>>"...value binding for the whole set of data". 10,000 rows, at a
> >>>maximum, or literally millions of rows? I guess I don't understand
> >>>what you're really looking for. If you want to keep the results in
> >>>session, yeah, they're in memory. Not millions of rows. Just
> >>>whatever your search results are. If you don't want to keep them in
> >>>memory you can try using the resultset datamodel implementation, which
> >>>I assume is not ripping through the whole result set and building a
> >>>version in memory or anything.
> >>>
> >>>I don't know how resultset keeps its data. I probably should figure
> >>>that out considering my chosen profession.
> >>>
> >>>If you're going to be working with huge results to link to data, this
> >>>might not be your best method. At results of that size, if this will
> >>>be a well traveled system, you might want to use something a little
> >>>more low level and link that into your faces code.
> >>>
> >>>However, 10,000 row result reports is begging for a different design,
> >>>IMHO.
> >>>
> >>>Dave wrote:
> >>>
> >>>
> >>>
> >>>>Normally we have filters to select a portion of data from database
> >>>>table. But it can be very large too. For example, searching found
> >>>>10,000 items. For the backend, ResultSet will have the 10,000
> >>>>records. I am trying to understand how the ResultSet manages the
> >>>>10,000 records. It would consume lots of memory if all of them in
> >>>>memory. For dataTable scroller, I still need to provide value binding
> >>>>for the whole set of data.
> >>>>
> >>>>*/Kevin Galligan <[EMAIL PROTECTED]>/* wrote:
> >>>>
> >>>> Out of curiosity, how are you planning to use the millions of
> >>>>rows? I
> >>>> would assume you'd want to filter them in some way rather than
> >>>>attempt
> >>>> to display them, right? That would kind of answer your question
> >>>>(your
> >>>> datatable would only have the filtered results. Not the full table).
> >>>>
> >>>> Mike Kienenberger wrote:
> >>>> > Data fetching would depend on your backing Collection.
> >>>> >
> >>>> > You can use t:dataScroller to limit the dataTable to accessing
> >>>>only a
> >>>> > subset of the data.
> >>>> >
> >>>> > I'd love to see a t:liveGridDataTable component like what's
> >>>>available
> >>>> > at this site, but I suspect it's currently outside of my
> >>>>ability to
> >>>> > implement.
> >>>> >
> >>>> > http://openrico.org/rico/livegrid.page
> >>>> >
> >>>> > On 9/8/05, Dave wrote:
> >>>> >
> >>>> >>For a large database table that has millions of records(rows),
> >>>> how is the
> >>>> >>memory managed from backend to ? all the millions of records
> >>>> >>are in memory? That would crash the system. Is the collection(
> >>>> returned from
> >>>> >>database layer) actually not filled with data until they are
> >>>> requested ?
> >>>> >>Thanks. Dave
> >>>> >>
> >>>> >>__________________________________________________
> >>>> >>Do You Yahoo!?
> >>>> >>Tired of spam? Yahoo! Mail has the best spam protection around
> >>>> >>http://mail.yahoo.com
> >>>>
> >>>>------------------------------------------------------------------------
> >>>>Click here to donate to the Hurricane Katrina relief effort.
> >>>><http://store.yahoo.com/redcross-donate3/>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>
