Using the December 2nd, 2015 build of SmartClient 10.0, it looks like clicking the "Clear Sort" option in a ListGrid header's context menu, doesn't invoke a data fetch. Is this intended behavior? There is a chance that some of my overrides causes this problem, but I don't expect it.
-
-
Anyone has an answer for this? My goal is to have a fetch performed as soon as the "Clear Sort" button is clicked from a ListGrid header's context menu. I'm not sure if I can really overrule the default code. -
Later I found out this ListGrid property is sort of doing this, although it's undocumented and perhaps "totally" wrong: invalidateCacheOnUnsort: true
Comment
-
It looks like my code breaks after 4,5 years. I see refreshes of data in my grids after I save records via the same data source. After disabling this invalidateCacheOnUnsort property, those refreshes disappear.
Has anything changed in the code in the last couple of months?
I will try to disable the setting now, but then I probably have my original problem back.
Any help is appreciated.Comment
-
I narrowed it down to changes between versions v12.0p_2020-03-29/LGPL and v12.0p_2020-04-01/LGPL. Somewhere in between this behavior seems to have changed. I'm not saying this is a bug or so, I was using the undocumented invalidateCacheOnUnsort property.
The 2020-04-01/LGPL is no longer available as download, but I've tried to compare the changes in my own code (where I had a copy of that release), but it's hard to "diff" the two versions.Last edited by wallytax; 8 Feb 2021, 08:36.Comment
-
Hi Wally,
clearSort() should not normally cause an immediate drop in cache. However, if the cache is partial, unsorting means that any new row requests will drop the existing cache (because we don't know how to reconcile the existing rows with newly fetched rows of a specific sort order).
Handling unsort() in this way is key, since it means that if a new record is added to local cache, we don't need to drop the existing cache right away, which would be bad/weird UE.
If there is some reason you want Clear Sort to also drop cache, then we would recommend customizing that menu item to perhaps call refreshData(), rather than attempting to use an undocumented API.Comment
-
I'm not sure why I wanted this back then (I surely had a good reason for it). Right now, I will not set the option and see what happens. I've tested quite long yesterday and noticed different behavior in the mentioned version (around April 1st, 2020, no fooling :-)). After founding out the difference there, I thought the problem was solved, but I most likely saw issues where the sorting order is lost after removing (or adding?) records. I've been struggling with refreshData(), fetchData(), initialCriteria, etc. quite some time now with SmartClient, which makes me feel quite insecure about whether I'm doing things right.
It's hard to create stand-alone examples to prove things or found out what I'm doing wrong. I've created some custom components which should help me interact between grids and forms, etc. Maybe my approach is incorrect. I will investigate further.Comment
-
I have debugged for another 4 (!) hours now, without any real result, but let me give you something that I have found, hoping that somebody knows what's going on.
The "invalidateCacheOnUnsort" option I mentioned has no direct cause to the problem. Somehow after saving a record, the sortBy gets cleared and therefore the sorting on the grid column disappears.
To summarize the whole problem (I'm working on a stand-alone example, this literally takes hours):
I have a ListGrid and ValuesManager (containing multiple forms, I need this to mimic HTML <FIELDSET> behavior via the "isGroup" property). Both components use the same DataSource instance (from a class made by me that inherits from RestDataSource). In the grid, I order by a field number and after I save the record via the ValuesManager, the order icon is gone. I'm trying to find out where that happens and of course, why it happens. It most likely has to do with custom code of myself and I try to narrow that code down to the bare minimum needed to work with my RubyOnRails back-end.
My feeling says that the sortBy on the request gets cleared and this causes the refresh of the data in case the invalidateCacheOnUnsort option is set to true. I've now disabled that option, so the data refresh is no longer there, but I see the order icon is gone and in case I refresh the data manually (I have a button on the screen for that), the ordering is gone.
Any help would be highly appreciated.Last edited by wallytax; 9 Feb 2021, 08:55.Comment
-
Hi Blama, thanks for your reply! Maybe it's the time of day and that I'm a bit tired, but I've not seen the "full solution". I'm pretty sure this issue was not there like a year ago. I've not changed my code when it comes to the sorting part, but can you point me into the right direction?
I've exactly what you've described in the "2" post I think. Why should the grid's order be removed after I save a record in another form? Place the created item in the grid's top row. Or let me refetch the data but then with the sorts applied as they were before the create. And like you asked, where to put that "resort" code?
After a day like today, I really wonder if I'm on the right track in using SmartClient like I do for more than 5 years.Comment
-
We already explained that it is correct and as-designed for sorting to be cleared if a new record is added to a partial cache:
This is also covered in the docs.Handling unsort() in this way is key, since it means that if a new record is added to local cache, we don't need to drop the existing cache right away, which would be bad/weird UE.
This is also just clearly correct: if a new record is added to a partial cache, or the sorted field modified in an existing record, then that data is no longer sorted and the sort indicator should disappear.
So, it's not clear what you have been debugging this whole time - this is correct behavior. It's also not clear what you want instead. In your #4 post you are complaining that invalidateCacheOnUnsort, an undocumented property, is doing what it says it does: invalidates the cache on unsort.
If you don't want to drop the cache in this case, then just stop using the undocumented property.
If you want the data to be shown as sorted again, then the only way to do that is to drop cache and go to the server. You can't safely sort a record into a partial cache!
Comment
-
For me, right now it would be sufficient to know that if I set updatePartialCache to true, adding a record does not remove the sort. The same would be true for updated records where the sorting field is updated. Your comments make sense, but as far as I know, this behavior is changed quite recently?!
It's hard to figure everything out that's included in the framework. Even after a couple years of experience. So I had no clue what happened and figured that I had broken certain behavior. Therefore I was debugging to see where things went wrong.
I've already stopped using the undocumented feature, but I originally switched that on to trigger a round-trip to the server as soon as the user clears the sorting at all, which is now malfunctioning. So, if I click the "Clear sort" button, nothing happens, maybe that's a mistake of my (overwritten) code, maybe not.Comment
-
updatePartialCache is true by default, which is why, when there is an update, the data is retained, but the sort indicator is cleared. This is all correct and expected.
If there is some other behavior you want here, please tell us what that is:
1. what do you expect to happen when there is an update on a partial cache
2. what do you expect Clear Sort to do, and in what circumstance?
a. when we have just updated a partial cache and are unsorted
b. when we are sorted but have a partial cache
c. when we are sorted but have a full cache
Note that way back when you said you wanted "Clear Sort" to always drop the cache. That's a very strange behavior, but, if you want it, we long since describes how to do it:
If there is some reason you want Clear Sort to also drop cache, then we would recommend customizing that menu item to perhaps call refreshData(), rather than attempting to use an undocumented API.Comment
-
To be 100% clear about what you're saying... partial cache means that only a subset of all available data is loaded into the grid, isn't? So this happens for instance when paginating.
So to answer the questions:- Could the record be left as-is in the view (in case of an update) and shown on the first row in case of a new record? Of course it doesn't apply to the sorting rules, but the data remains visible in the grid until a refresh is performed, in which case the sorting should still apply. Maybe it's me thinking strange, but I would say this is rather intuitive.
- a) If the data was already unsorted, I think nothing should happen.
b/c) Refresh the data (at least for remote data)
Comment
-
1. this is what happens, as the docs already say
2. b/c this is definitely not what most people desire. For both b & c, it also has the potential for an updated record to vanish from the viewport, for reasons that may not be obvious to the user. For (b), it creates unnecessary load on the server.
But you can force it when the form saves if you like.
Comment
Comment