On 01/23/2013 11:02 AM, Peter Schneider wrote:
>>
>> So you requesting getRowCount multiple times, the row count effectively
>> changes on the server, but the changed count is not available on the
>> client, is that right?! And you don't see subsequent getRowCount calls
>> being translated into network requests that actually reach your server,
>> right?!
> Right! (See attachment "DemobrowserFireBug.png", too)

Mh, actually your screenshot might prove the contrary: I see three 
requests for getRowCount to the backend, which return distinct values. 
What I don't see is how many calls to getRowCount in the JS code have 
triggered these three requests. So if I assume there were also three 
calls being made, then everything looks just fine to me: 3 calls, 3 
requests, 3 individual answers from the backend!?

>
> I changed the demobrowser application a bit to reproduce it here. This
> reproduces the issue 100% on my local machine!
> (see attachment "demobrowserChanges.zip")

Patches to the Demobrowser are awkward. But you can attach it to the bug 
anyway. It would be better to attach a real patch, though, rather than 
replacement files.

>> The interesting question is whether our IO layer is issuing XHR requests
>> at all. You should be able to tell this from e.g. the Network tab of
>> your browser console, or using some qx.io debug settings.
>>
>> But given the fact that your simple change has such a profund effect,
>> you might open a bug for it so we can have a deeper look. But as a
>> prerequisite you need to devise a Playground example that reliably
>> reproduces the issue in your environment, e.g. by just issuing
>> getRowCount calls that don't get translated into network requests
>> eventually. Make note in the bug that the problem is not visible in the
>> Playground GUI, but only when looking into the network layer and looking
>> for the missing request.
> I have also attached the Header information that is going over the Network.
> maybe this explains something (attachment "DemobrowserFireBugHeaders.png").
> It's from the same "session" as the other picture.

As with the other screenshot this is not indicative, as it only shows 
successful network requests, but without context.

>> Make also a note that the issue persists even
>> when you clear the browser cache after every getRowCount call (provided,
>> of course, all of the previous proves true). Without a setup that lets
>> us reproduce the issue reliably we cannot do much.
> How can I clear the browser cache after a getRowCount call? Any qooxdoo magic
> I can add to the callback handler?

Look, it's not about doing qooxdoo magic, it's about a reliable recipe 
that allows us to reproduce the behavior in our environment, leaving 
away all non-essential things.

I thought of a simple Playground sample that exhibits a "getRowCount" 
button, which when pressed would perform the getRowCount() call and 
display the result in a label. Now you could press the button, check the 
net tab for a request, check the server logs for a request, check a 
proxy or packet sniffer for a request, .... Then open a browser menu, 
delete the browser cache, push the button again, check the net tab, etc. 
etc...

This would be a simple and effective setup to investigate if and how 
getRowCount() calls are translated into network requests that actually 
go to the server.

>
> So when I am using the '1.2.x branch' version of qx.ui.table.model.Remote, I

You still mean 2.1.x, right?!

> definitely get this "only Count, no data" problem.
>
> Would be nice if someone could explain this (maybe it's a server setting, but
> I doubt, 'cause the changes in qx.ui.table.model.Remote#reloadData() should
> not change that behavior ;)

If I understood it so far the issue boils down to the question "Are 
getRowCount() calls being translated into network requests every time?". 
This is a question we can investigate.

> If the information I have give here does not explain my issue, please tell me
> and I'll add a bug with this info.

Yes, the question as I pinned it above is not resolvable on the ML and 
requires a bug to work on. But please make sure you provide a Playground 
sample and recipe as formulated above to reproduce the issue.

T.


------------------------------------------------------------------------------
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