Skar,
Just a quick note - the patch that Derrell and I worked out last month
to avoid the numerous RowCount calls essentially prevented multiple
calls when one was already pending, blocking concurrent rowcount
requests. If the remote table class requests a rowcount when there's
not one pending, it should not be affected by that patch back in June.
One caveat:
>From this patch, it's important to point out that the developer's class
code that extends the Qooxdoo framework class qx.ui.table.model.Remote
should insure that the "flag" for this concurrent request blocking is
reset whenever a reload is requested BUT NEVER ACTUALLY PERFORMED, as
the concurrent flag gets set on the way into the reload method. This is
not necessary if you always retrieve data through the RPC calls, but
it's important if your code ever blocks the actual RPC calls to the
server.
As an example, I have an implementation where I request filtered row
data through the RPC backend, but I block the RPC request for data
whenever my application doesn't have an appropriate filter value.
Everything works fine if the RPC backend returns a zero row count, but
in my situation the server would actually return ALL available data rows
without an appropriate filter value, so I block that scenario and reset
the concurrent rowcount blocking flag by forcing a rowcount of "0" as
shown below...
If you have this same scenario in your application, in your
"_loadRowCount" method for your extended class, make sure that you make
the following method call to force the row count to "0" whenever your
_loadRowCount method decides that it doesn't want to request any data
from the RPC backend...
this._onRowCountLoaded();
otherwise, later row count requests (and data requests) may end up being
blocked by the implemented patch. Calling this method without a
parameter forces the rowCount to zero and resets the concurrent rowcount
blocking flag.
Gene
On Fri, 2009-07-31 at 10:05 -0400, Derrell Lipman wrote:
> On Fri, Jul 31, 2009 at 09:35, skar <[email protected]>
> wrote:
>
> Yup, fetching the new row count should move the scroll bar to
> the right
> place. So, if user is on row 20 out of 200 and then when he
> scrolls to
> the next page by pressing down arrow for 1 block size or by
> pressing
> page down, then new row count should also be fetched. Now, if
> there are
> 100 more rows, user will be 1/3 of the table down in the
> scroll bar
> rather than just 20 rows down.
>
> Also, whenever data is fetched, a timer should be reset and
> when timer
> runs out, it should fetch the latest row count and adjust
> data/scroll
> bar position accordingly. The timer interval should be an
> option too. Of
> course, this whole auto-refresh, row count refresh etc should
> be on/off
> via config settings, as most users won't be needing that, but
> in places
> where it's needed, it can be used.
>
>
> I'll be glad to review, next week, the patch you provide over the
> weekend that implements this properly. :-)
>
> Derrell
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________ qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
