Hi Thomas,
first: my last post was a tiny bit to big for the mailing-list, so it has been
send again by me. The content is the same, only the attached PNGs are
size optimized. Sorry for any confusion it might have caused.
On 1/23/2013 11:58 AM thron7 wrote:
> 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.
I just called "reloadData" three times! That's the whole issue here ;)
>From the demobrowser applications point of view:
* I clicked 3 times the "Reload" button,
* which only calls "_tableModel.reloadData();",
* which should result in 3 "getRowCount" & "getRowData" RPC calls.
> 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!?
See my explanation above.
>>
>> 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.
If I could reproduce this with a playground example I would have done it!
The demobrowser "patch" was just to show you what was really done.
A (regression-)test might be better for this, but I have limited
(read: none) knowledge on how to check rendering results in tests.
>>> 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.
When you think you need some more information that I can provide, please tell
me.
>>> 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.
Yes, but you said I should [...]clear the browser cache after a getRowCount
call[...]
That can only be done programatically , when I only call reloadData!
Again: the problem is not at "getRowCount" or "getRowData", it's with
"reloadData".
> 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.
No problems with "getRowCount" or "getRowData". Those work (in general).
(see above)
The table requests its Data correctly from the backend at startup:
getRowCount => value not zero => getRowData => render viewport
So that "test" doesn't prove anything.
>> 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?!
Damn ;)
I hate it when that happens! Yes you're right, I am talking about 2.1.x
(all the time)
>> 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.
Any call to "reloadData" results into a "getRowCount" call *every time*. I
just seems that the next step (a call to "getRowData") is skipped.
>
>> 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.
I will file a bug later this day or tomorrow when no quick "aha!" evolves
earlier ;)
>
> T.
/Kuddel
------------------------------------------------------------------------------
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
