we are getting off track though.
suppose class result { int size; iterator data } and idataprovider {
result getdata(int first, int count); }
how do we handle usecases where we just need the size and dont know
first/count yet?
-igor
On Wed, Mar 26, 2008 at 7:19 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> see below...
>
>
> -----Original Message-----
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
>
> Sent: Monday, March 24, 2008 5:13 PM
> To: users@wicket.apache.org
> Subject: Re: DataView size() iterator() call order issue
>
>
>
> how are we going to cover these usecases:
>
> * pagination toolbar needs to call dataprovier.size() to figure out
> how many total records there are. at this point the toolbar doesnt
> know what window of data to retrieve, it just wants to know the size.
> [Will]: Currently, the size() method is called twice when paginating using
> PagingNavigator (not to mention the call for isvisible you describe below).
> This causes issues with duplicate query calls if the count is queried in the
> size() method. Could there be transient properties in the data provider that
> cache the count/list of items that would be cleared when rendered? If that
> were the case there could be an abstract method defined in the data provider
> interface to query/set the results.
>
>
> * often users do:
> new dataview() { isvisible() { return dataprovider.size()>0; }
> once again, datawindow size is not known.
> [Will]: This would be accommodated by the above solution.
>
>
>
> -igor
>
>
>
> On Mon, Mar 24, 2008 at 6:52 AM, Hoover, William <[EMAIL PROTECTED]> wrote:
> > We are using a modified version of the Generic DAO for Hibernate
> (http://www.hibernate.org/328.html) where we make reuse of common DAO methods
> such as keyword searches that retrieve corresponding entities as well a total
> size (both use the same search criteria when determining results so it makes
> sense to combine the operations). As you stated, we are making two calls the
> database, but only one call to the DAO (although, as stated in previous
> responses there are alternative ways to perform one query to achieve this).
> >
> > Our business tier handles the transactions for us (not our DAOs ;o) using
> an event model (similar to typical BPM systems). Broadcast agents are used to
> notify our business listeners which in turn process our DAO calls. This gives
> us an the flexibility to have independent transactions for different business
> rule operations and makes the most out of code reuse.
> >
> > Avoiding the heavier call makes perfect sense, but couldn't this
> responsibility be passed to the data provider implementation? It may make
> more sense if the operation were combined so that the implementation could
> determine how/when to make the call to the persistence tier for the two
> operations. I guess I'm not seeing why we need the count before the iterator.
> The data provider impl can determine whether or not it will make the
> expensive call for the results.
> >
> >
> > -----Original Message-----
> > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> >
> > Sent: Friday, March 21, 2008 2:44 PM
> > To: users@wicket.apache.org
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> >
> >
> > knowing the size and the window together seems like a ui requirement,
> > it is a bit strange to me that you have it inside a dao which should
> > cater to business logic. eg, as far as i know there is no single db
> > operation that will produce both, so you are still doing two calls
> > inside the dao.
> >
> > also transaction management should be handled outside the dao, daos
> > are too fine an object to implement transaction management for.
> >
> > anywho, just nitpicking :)
> >
> > size() is called first for a lot of reasons, namely even knowing if
> > there are any rows to retrieve before a much heavier iterator() is
> > called. some clients want to hide a repeater if there are no items
> > visible, and so size() might get called from inside isvisible() as
> > well.
> >
> > idataprovider is quiet old and we havent had many complaints about its
> > design so far. if all you are using is the dataview it should be
> > pretty simple for you to roll your own dataview, if you look at
> > dataview all it does is implement idataprovider handling to feed the
> > pageable view. however, if you do you will also lose datatable as well
> > :|
> >
> > if you got suggestions on how to improve it im all ears.
> >
> > -igor
> >
> >
> > On Fri, Mar 21, 2008 at 11:24 AM, Hoover, William <[EMAIL PROTECTED]>
> wrote:
> > > When using DataView/IDataProvider size() is called before iterator(int
> first, int count) causing calls to DAOs to be duplicated. Our current
> framework that is internally using Hibernate allows one call to be made to a
> DAO that returns both the total result size and the actual records (based off
> first/count). The problem is that the first and count are unknown until the
> iterator method is called- forcing multiple calls to the DAO to retrieve the
> data (also forcing multiple transactions). What are the reasons behind
> calling size before iterator?
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
