On Mon, Apr 14, 2008 at 12:54 PM, Ralf Nieuwenhuijsen <
[EMAIL PROTECTED]> wrote:
> Can this be applied to trunk? My current workaround is much fuglier. (i
> just added a complete layer in between that managed its own remoterequest
> calls), but that would still give the 'blank' table for a second problem
> when refreshing the data; rather than just a smooth update. (ie. no visual
> impact if none of the data has changed)
I am very interested in this proposal, but it needs to be looked at *very*
carefully to ensure that it won't break anything. I'm concerned that
there's an opportunity for a request to retrieve the count while it is
locked. That may never occur, but I need to convince myself of that. When
I get a chance, I will look at it, but that won't likely be in the next
week.
Derrell
>
> 2008/4/14, kanugula <[EMAIL PROTECTED]>:
>
> >
> > Well, I made a workaround to this. I added couple of lines in
> > _loadRowCount()
> > to prevent multiple firings.
> >
> > _loadRowCount: function ()
> > {
> > if (this.blockRowCount == undefined) {
> > this.blockRowCount=true;
> > }
> > else {
> > return;
> > }
> >
> > // Call to Backend for rowCount()
> > ...................
> >
> > }
> >
> > //Overriden reloadData() to reset any state varriables
> > reloadData : function() {
> > this.blockRowCount=null;
> >
> > this.base(arguments);
> > }
> >
> > This works perfectly to me and I don't see any performance issues with
> > it,
> > even if the backend for rowCount() takes 2 minutes for 100,000 rows, it
> > still works great!
> >
> > I hope this will help somebody if they have same problem.
> >
> > Thanks.
> > Kanugula.
> >
> > Derrell Lipman wrote:
> > >
> > > On Fri, Apr 11, 2008 at 3:57 PM, kanugula <[EMAIL PROTECTED]
> > >
> > > wrote:
> > >>
> > >> I have seen the RemoteTable fires _loadRowCount() multiple times
> > >> (ranging
> > >> from 2 - 30 times) depending on row count.
> > >> Only after the last _loadRowCount() is finished, it calls
> > >> _loadRowData().
> > >>
> > >> I am guessing that _loadRowData() is called only AFTER building the
> > >> Table
> > >> with empty rows of reutned Row Count size.
> > >>
> > >> If my assumptions is correct, why can't we build the empty table (if
> > >> not,
> > >> atleast for block of Pages in the background)?
> > >>
> > >> Firing _loadRowCount() multiplen times may not be an issue in my
> > case,
> > >> but
> > >> the delay caused by filling up empty table for large number of rows
> > (say
> > >> 10000 rows) is showing a blank screen for a long time.
> > >
> > > This is a known problem that requires reworking the way requests for
> > > row data are issued by Table. Currently, IIRC, the remote table model
> > > isn't notified of a pending need for data until the need is immediate
> > > (or nearly so). The calls to the backend are thus made at the time
> > > that the table needs refreshing. That's too late. There are already
> > > hooks to allow pre-fetching data, but they're called at just about the
> > > same time as the need for that data so it's not really pre-fetched.
> > >
> > > I've wanted to get around to reworking this code for a while, but just
> > > haven't yet found the time. It is certainly an area that could use
> > > some work.
> > >
> > > Derrell
> > >
> > >
> > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > > Don't miss this year's exciting event. There's still time to save
> > $100.
> > > Use priority code J8TL2D2.
> > >
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > > _______________________________________________
> > > qooxdoo-devel mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> > >
> > >
> >
> > --
> > View this message in context:
> > http://www.nabble.com/RmoteTable-fires-_loadRowCount%28%29-multiple-times-for-very-1st-request-tp16628238p16678569.html
> > Sent from the qooxdoo-devel mailing list archive at Nabble.com.
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> >
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > qooxdoo-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
>
--
"There is nothing more difficult to plan, more doubtful of success, nor more
dangerous to manage than the creation of a new system. For the initiator has
the enmity of all who would profit by the preservation of the old system and
merely lukewarm defenders in those who would gain by the new one."
--Machiavelli, 1513
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
