forgot:
public class MYSizeCachingDataProvider ... {
public void detach() {
size = null;
resultset = null;
}
}
On 3/27/08, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> public class MySizeCachingDataProvider implements IDataProvider {
> private Integer size = null;
> private List<Foo> resultset = null;
> public int getSize() {
> if(size == null ) {
> performExpensiveQuery();
> }
> return size;
> }
> public Iterator iterator() {
> if(resultset == null ) {
> performExpensiveQuery();
> }
> return resultset;
> }
> private void performExpensiveQuery() {
> size = count();
> resultset = query();
>
> }
> }
>
> On 3/27/08, Hoover, William <[EMAIL PROTECTED]> wrote:
> > I'm only interested in caching it for the current request so there isn't
> multiple calls to size within the same request. The same way
> AbstractPageableView is caching it and clearing it in "onBeforeRender". The
> only problem is that:
> >
> > 1) I do not have access to the cached size stored in AbstractPageableView
> -> cachedItemCount from within the data provider
> > 2) The cached size in AbstractPageableView -> cachedItemCount is
> "cleared" in onBeforeRender() before the call is made to getViewOffset() ->
> getCurrentPage() -> getPageCount() -> getRowCount() when getting the item
> models in getItemModels(); This causes a second call to the data providers
> size() method when paginating. In other words, the AbstractPageableView ->
> cachedItemCount is not working properly when a link for the PagingNavigator
> is clicked- causing 2 calls to the size() method within the same request (w/o
> deletions ;o).
> >
> >
> > -----Original Message-----
> > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> >
> > Sent: Thursday, March 27, 2008 11:36 AM
> > To: [email protected]
> > Subject: Re: DataView size() iterator() call order issue
> >
> >
> > If you are iterating over a list that can be changed by all kinds of
> > different users
> > Then you cant really cache it
> >
> > If you are iterating over a list that is pretty stable for the current
> users
> > or the user itself only alters that list (insert/delete)
> > Then you can cache it easily
> >
> > Just call detach (that clears the size cache) when you have an action that
> > deletes or inserts a new items so that you know the size is changed.
> >
> > johan
> >
> >
> > On Thu, Mar 27, 2008 at 4:04 PM, Hoover, William <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Can you post code for an example data provider that would KNOW how to
> > > cache the size?
> > >
> > > -----Original Message-----
> > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, March 27, 2008 10:47 AM
> > > To: [email protected]
> > > Subject: Re: DataView size() iterator() call order issue
> > >
> > >
> > > no you as a developer KNOW that it can cache it
> > > Cache it if you can dont if you cant
> > >
> > > On Thu, Mar 27, 2008 at 2:28 PM, Hoover, William <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > Okay, two issues... (1) combined call for size/data (2) multiple calls
> > > to
> > > > size() when paginating
> > > >
> > > > I will avoid confusion by addressing only the multiple calls to size()
> > > for
> > > > now.
> > > >
> > > > If only the size was to be cached, as you suggested, how would the
> data
> > > > provider know when to clear it? The data provider is statefull and
> > > maintains
> > > > the size across requests and there is no "onBeforeRender" in a data
> > > provider
> > > > like there is in AbstractPageableView. So, the size will never be
> > > cleared
> > > > when paginating from one page to the next. Even if we were able to
> cache
> > > the
> > > > size we would be maintaining the same data in two different locations-
> > > in
> > > > the AbstractPageableView -> cachedItemCount and in the data provider.
> > > >
> > > > -----Original Message-----
> > > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > Sent: Thursday, March 27, 2008 8:12 AM
> > > > To: [email protected]
> > > > Subject: Re: DataView size() iterator() call order issue
> > > >
> > > >
> > > > no cache the size.
> > > > We first have to have the size to be able to give you the offset and
> > > count
> > > > params.
> > > > And depending of the type of data or the database you use you could
> also
> > > > already query the data (in the size() call)
> > > > But i know that is not always the best thing to do.
> > > >
> > > > But do you want an extra 2 params also in the size() call?
> > > > What would be the offset and what would be the max length?
> > > > The problem is that both of those depends on the size call.....
> > > > So the offset is calculated with the size param as is the count..
> > > >
> > > > So if we try to guess those 2 params for the size() call then those 2
> > > > params
> > > > dont have to be the same for the iterator call...
> > > >
> > > > johan
> > > >
> > > >
> > > > On Thu, Mar 27, 2008 at 1:01 PM, Hoover, William <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Also, you mention that all that is needed is to cache it (I assume
> you
> > > > are
> > > > > referring to the actual data) in the data provider. How can that be
> > > done
> > > > > when the size is being called when there is no way to get the
> current
> > > > offset
> > > > > that is needed to get the data in the first place?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Hoover, William [mailto:[EMAIL PROTECTED]
> > > > > Sent: Thursday, March 27, 2008 7:55 AM
> > > > > To: [email protected]
> > > > > Subject: RE: DataView size() iterator() call order issue
> > > > >
> > > > >
> > > > > The difference is that in the deletion scenario the state of the
> data
> > > > has
> > > > > changed. In the pagination scenario the state of the data has not
> > > > changed.
> > > > > Why is that so difficult to differentiate?
> > > > >
> > > > > -----Original Message-----
> > > > > From: Johan Compagner [mailto:[EMAIL PROTECTED]
> > > > > Sent: Thursday, March 27, 2008 7:49 AM
> > > > > To: [email protected]
> > > > > Subject: Re: DataView size() iterator() call order issue
> > > > >
> > > > >
> > > > > and how do we know the difference?
> > > > >
> > > > > You as a developer know it, we dont know it as a framework, just
> cache
> > > > it
> > > > > in
> > > > > your dataprovider or wrap in in a caching data provider. Why is that
> > > so
> > > > > difficult
> > > > >
> > > > > johan
> > > > >
> > > > >
> > > > > On Thu, Mar 27, 2008 at 12:39 PM, Hoover, William <[EMAIL PROTECTED]
> > > >
> > > > > wrote:
> > > > >
> > > > > > That makes perfect sense in the scenario where rows are deleted,
> but
> > > > it
> > > > > > doesn't make sense when all that is being done is clicking the
> next
> > > > > button
> > > > > > for a PagingNavigator. Why would do we need two calls to the size
> > > > method
> > > > > in
> > > > > > that scenario?
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> > > > > > Sent: Wednesday, March 26, 2008 3:27 PM
> > > > > > To: [email protected]
> > > > > > Subject: Re: DataView size() iterator() call order issue
> > > > > >
> > > > > >
> > > > > > On Wed, Mar 26, 2008 at 11:37 AM, Hoover, William <
> > > [EMAIL PROTECTED]
> > > > >
> > > > > > wrote:
> > > > > > > 2) Although AbstractPageableView does ensure the cached item
> > > count
> > > > is
> > > > > > used before calling the data provider size() in getRowCount(), the
> > > > > cached
> > > > > > item count is "cleared" in onBeforeRender() before the call is
> made
> > > to
> > > > > > getViewOffset() -> getCurrentPage() -> getPageCount() ->
> > > getRowCount()
> > > > > when
> > > > > > getting the item models in getItemModels(); This causes an
> > > unnecessary
> > > > > > duplicate call to the data providers size() method when
> paginating.
> > > > > >
> > > > > > it is not unnecessary
> > > > > >
> > > > > > suppose you have a dataview with overridden isvisible() { return
> > > > > > getitemcount()>0; }
> > > > > > inside this dataview you have a delete link
> > > > > >
> > > > > > suppose dataview loads and has 1 item.
> > > > > > user clicks delete
> > > > > > wicket checks the link is indeed visible - which results it the
> > > size()
> > > > > > call which in turn caches the result
> > > > > > onclick() handler is invoked
> > > > > > row is removed
> > > > > > onbeforerender is called
> > > > > > dataview is rendered
> > > > > >
> > > > > > in this case dataview is rendered because getitemcount() has been
> > > > > > cached before onclick() has been executed, so the cached count is
> 1
> > > > > > when in reality there are now 0 items. that is why
> onbeforerender()
> > > > > > clears the cache, and why sometimes you will get two size() calls.
> > > > > >
> > > > > > -igor
> > > > > >
> > > > > >
> > > ---------------------------------------------------------------------
> > > > > > 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]
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.2 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
