A XHR call can be chached be browser. Nocache param is a common solution but 
makes unnecessary traffic, if nothing changed. A well configured web server 
which handles last modification time and etags can be helpful to work more 
elegant with browser cache (HTTP Code 304). 

Mustafa Sak

Applications & Integration

1&1 Internet AG
Ernst-Frey-Straße 10
DE-76135 Karlsruhe


-----Ursprüngliche Nachricht-----
Von: Peter Schneider [mailto:[email protected]] 
Gesendet: Dienstag, 22. Januar 2013 13:42
An: qooxdoo Development
Cc: Mustafa Sak
Betreff: Re: qx.ui.table.model.Remote::reloadData() issue in 1.2.x branch

Hi Mustafa,

I can verify, that the table is still not updated with correct (new) data, when 
using your link.
But after looking at the RPC results I found that those aren't changing!
Some kind of caching might prevent reliable test results here.

When I add a "nocache" parameter to the RPC request at _loadRowData, like:
<code lineNo=25>
      var param = "method=getRowData&start=" + firstRow + "&end=" + lastRow + 
"&nocache=" + qx.lang.Date.now(); </code> The data is reloaded and displayed 
correctly!
So the current master/trunk seems to work! Hmmmmm...

Is there anything you've changed at master/trunk so far?


/Peter

On 1/22/2013 12:38 PM Mustafa Sak wrote:
> Hi Peter,
> 
> I tested your code in playground and could not see your described 
> issue. Here is the short link: http://tinyurl.com/agytrvp
> 
> Please verify again.
> 
> Mustafa Sak
> 
> Applications & Integration
> 
> 1&1 Internet AG
> Ernst-Frey-Straße 10
> DE-76135 Karlsruhe
> 
> -----Ursprüngliche Nachricht-----
> Von: Peter Schneider [mailto:[email protected]]
> Gesendet: Dienstag, 22. Januar 2013 10:04
> An: qooxdoo Development
> Cc: Mustafa Sak
> Betreff: Re: qx.ui.table.model.Remote::reloadData() issue in 1.2.x 
> branch
> 
> Hi Mustafa,
> 
> as I already said it's hard to reproduce in the playground... 
> Especially, if you don't have control over the backend ;)
> 
> But I tried. And I think I've found a test-case to reproduce the issue.
> (unfortunately I can't provide a "shortened URL", cause our Network 
> here behaves evil...) Anyway... with the attached code (to be run at
> http://demo.qooxdoo.org/devel/playground/index.html) you should be able to 
> reproduce the issue.
> Function:
> - Each time you click on reload, the reloadData() method is called.
> - Due to the fact that I haven't any control over the backend, I alter the
>   "getRowCount" RPC-result every 2nd time (alternating returning 1000 or 500).
> Result:
> - You will see that the row-count indication will change, but the rendered 
> data
>   still displays the old data (it should display a 'newer' date) Expected 
> Result:
> - You should see that the row-count indication will change, *AND* the rendered
>   data displays the new data (it displays 'newer' dates)
> 
> 
> Regards,
>   Peter
> 
> 
> On 1/21/2013 6:37 PM Mustafa Sak wrote:
>> Can you please provide us with an example, like in demobrowser[1]? 
>>
>> Please build it against current master.
>>
>> Thanks
>> Mustafa Sak
>>
>>
>> [1]
>> http://demo.qooxdoo.org/devel/demobrowser/index.html#table~Table_Remo
>> t
>> e_Model.html
>>
>> Applications & Integration
>>
>> 1&1 Internet AG
>> Ernst-Frey-Straße 10
>> DE-76135 Karlsruhe
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Peter Schneider [mailto:[email protected]]
>> Gesendet: Montag, 21. Januar 2013 17:28
>> An: qooxdoo Development
>> Cc: Mustafa Sak
>> Betreff: Re: qx.ui.table.model.Remote::reloadData() issue in 1.2.x 
>> branch
>>
>> Hello Mustafa,
>>
>> thanks for the input, but I don't like "picking randomly from 
>> trunk/master", 'cause that would definitely introduce a randomness to 
>> the stability of my application ;)
>>
>> Although it still isn't guaranteed that a branch is any better than 
>> trunk/master, I tend to think that
>> * "tags" are most stable,
>> * "branch"es are a bit less stable but needed for FIXES,
>> * "trunk/master" is 'only for the brave' ;)
>>
>> O.K. Back to topic:
>> I see that the master looks exactly like the branch I've checked out. So the 
>> error occurs with a master-checkout as well! When I revert the changes of 
>> master:d4cd43114dcd6ee22346aa3778a170973c231448, My application behaves well 
>> again. It might not be optimal for other cases, but the "fix" for Bug#7111 
>> definitely introduces a regression here.
>>
>> Thanks so far,
>>  Peter
>>
>>
>> On 1/21/2013 3:28 PM Mustafa Sak wrote:
>>> Hi Peter,
>>>
>>> the last changes are made to master, because we have to write some 
>>> unit test. So please try your code against master
>>> ba147769cf924ef3ae8c45c5ef4057be2b352474
>>>
>>> regards
>>> Mustafa Sak
>>>
>>> Applications & Integration
>>>
>>> 1&1 Internet AG
>>> Ernst-Frey-Straße 10
>>> DE-76135 Karlsruhe
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Peter Schneider [mailto:[email protected]]
>>> Gesendet: Montag, 21. Januar 2013 15:01
>>> An: qooxdoo Development
>>> Betreff: [qooxdoo-devel] qx.ui.table.model.Remote::reloadData() 
>>> issue in 1.2.x branch
>>>
>>> Hi there,
>>>
>>> I've come along an issue with the remote table models reloadData() method.
>>>
>>> It seems to me that the row count is requested (from backend) and updated, 
>>> but the (requested and received) row data will not be re-rendered!
>>> The Table still shows the "old" data!
>>> In my case the row count is reduced due to an applied filter. As an example:
>>> a) 1000 rows (containing odd and even numbers)
>>> b) Apply filter (only odd) + reloadData() => Table info-bar shows that 
>>> getRowCount received 500 (OK) => Table Scroll-bar indicates that only 500 
>>> rows should be shown (OK) but NO getRowData RPC and NO re-rendering of the 
>>> current 'view-port'.
>>>
>>> Only if I e.g. change the order of one Column, a getRowData RPC call is 
>>> done and the result is like expected.
>>>
>>> I have the suspicion, that the last change for Bug#7111[1] did introduce 
>>> this issue.
>>> Could it be that the move of the "this._clearCache = true;" line @ 
>>> reloadData is not correct?
>>>
>>> I've tried to create a playground example for this, but I didn't 
>>> succeed...A real backend might be needed to reproduce the issue.
>>>
>>> Any help/insight would be highly appreciated,
>>>
>>> Regards,
>>>   Peter
>>>
>>> ---
>>> [1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=7111

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to