[Isomorphic]

This cross-post about the tree of samples is not the correct scenario.

The actual scenario is an update to a never-loaded record.

The user could not actually use a DynamicForm to edit the record unless it had been loaded because they had navigated to it in some way, in which case, the grid or tree component they had used to navigate to the record *would* actually show the updated record, leaving it in the same position where the user saw it.

Which is correct and expected.

Again, to re-open this discussion, we need multiple valid, real-world scenarios as previously described. And to avoid too much more wasted time, we would really appreciate it if you could wait at least a day to thoroughly consider the existing replies from Isomorphic before posting again.

[edulid]

Again, let's get some perspective.

Very simple application scenario: a list of all supplyItems adjacent to a list of supplyItems with low stock.

It is obviously not right that updating the list of low stock items causes whatever was updated to pop to the top of the complete list of supplyItems when it was not even visible there before, which would needlessly prominently display data already visible elsewhere, and create a situation where scrolling down would force cache to be dropped unnecessarily.

We'd encourage you to run through *several* thought experiments with other kinds of entities in other applications before responding again. You should quickly come to an understanding of why the behavior you want is not the right default, which is why no one else is reporting it as a bug.

If you still somehow feel that the framework behavior is not the right behavior, we need examples of *multiple real-world application scenarios* which involve *specific, real-world use cases with actual business entities* (for example, users and accounts, not something synthetic like "testDataSource") where the framework behavior is clearly wrong *from a usability perspective* - and then we could continue the discussion.

And again just to hopefully avoid any more wasted time on this - we're sure this behavior does makes sense in your particular application. What we're saying is simply that it's not the right *default* behavior and it's not a common enough requirement that we're going to prioritize it over all other planned features. You can either add application code for the behavior you want, or use Feature Sponsorship to get it added, as is an option for any enhancement.

Ok, in this simple application scenario you described you are right, your behavior is the right behavior.
As I said, I don't need you to change the default behavior :)

Another, very simple, and in my eyes, a common usecase:

You have a listGrid showing software issues to a software developer, which is ALWAYS open in the application. This listgrid shows software issues having some criteria. This criteria is dynamically changed, depending on what the software developer chooses (for example: one button changes the criteria to "fixed"=false and shows the results in the listGrid. For example: buttons "fixed", "not-fixed".).

So, if the software developer does not push any other button, he has a view of the database with a specific criteria, e.g. all software issues which are NOT fixed, i.e. with criteria fixed=false.
He calls this listGrid: "open-issues"-ListGrid.

He clicks on one of these software issues. He fixes the issue, and then he updates the "fixed" field of this issue to true.
So the software issue disappears from the open-issues-list-> the software developer is happy: an issue is fixed!!

Unfortunately, the end-user reports that the issue is STILL NOT SOLVED, so the software developer has to open this issue again. The update-form is still open, so the software developer doesn't have to navigate to the issue: it's already open. He changes the issue's "fixed" field to false again, since the issue has to be revisited and investigated again.

----> The open-issues-listGrid is not updated accordingly! The software developer does not see the open issue in the list of open issues!
----> The software developer doesn't know where to look for this issue if he closes the form. The only solution is to click some button, which calls invalidateCache() on the listGrid.

Is this a fictive usecase? I think not.

My real usecase is very similar: the only difference is the amount of criteria shown.

[edulid]

Again, to re-open this discussion, we need multiple valid, real-world scenarios as previously described. And to avoid too much more wasted time, we would really appreciate it if you could wait at least a day to thoroughly consider the existing replies from Isomorphic before posting again.

Ok. Nevertheless, please take a look at my software-developer-issues usecase: http://forums.smartclient.com/showpo...0&postcount=32 . I think a LARGE amount of simimlar usecases may be derived from this usecase,..

And to your question:
"unless it had been loaded because they had navigated to it in some way" -> There are a LOT ways to navigate to an issue, without using the listGrid. You can use other listgrids, trees, etc.

I will think about other use cases, but please take a look at my software-developer use case.

[edulid]

As I checked my post using Thunderbird, I clearly saw another use case:

Open the "Inbox" ListGrid. Double click on one message. It opens in a new Tab. The Inbox listGrid uses a datasource "inbox", and the message a datasource "message", so you need relatedUpdates() to inform the inbox-listgrid when the message status changes. The message-status is the criteria.
Push the "Delete" Button in the new Tab. The message disappears from the "Inbox" ListGrid in the "Inbox"-Tab.
(You see this if you change the tab to the "Inbox" Tab, leaving the other tab open).
The message dissapeared from the "Inbox" ListGrid.

----> Until now, we see SmartGWT's default behavior.

Now, go to the message tab again, which is still open. Click on the "Undelete" Button. You would expect this message now in your "Inbox" ListGrid, but, according to SmartGWT's default behavior, if you change the tab to the "Inbox"-Tab, you don't see the Message in the "Inbox"-ListGrid.
----> Where is your undeleted message???? It should be in your inbox!

This usecase applies for ALL usecases having similar, tabbed GUIs.

[Isomorphic]

Both scenarios are wrong in the same way.

Again the behavior we are talking about is whether an update to a record that is not currently cached *should pop to the top of a ListGrid by default*.

In both scenarios you describe, if there is an update to a record that is not currently visible to the user because it hasn't been loaded, they can discover it by scrolling down - in exactly the same way they would discover it if it had not been updated.

But to anticipate your next confusion - in both cases you are touching on the possibility of real-time updates. But if the behavior of ResultSet were changed to what you expected, it would not actually handle the real-time update scenario, nor would it bring you any closer to solving it, because:

1. when updatePartialCache is active,

The cache will then be dropped the next time rows are fetched, to prevent problems with inconsistent row numbering between the server and client, which could otherwise lead to duplicate rows or rows being skipped entirely.

In order to *safely* update a partial cache and be sure that the cache matched the server row order, so that further paging could continue without dropping the cache, the ResultSet would need to be aware that it was receiving *all* updates to the server dataset - but the ResultSet cannot know this

2. if real-time updates are being pushed, there have to be limits on total number of rows retained or the application will eventually run out of memory. Here again, the ResultSet does not have enough information to impose a reasonable limit.

Because of these factors, both real-time updates and your possibly-related requirements are best handled as we already explained:

Instead, what you might want to do in this use case is to grab the data in the existing ResultSet and create a new ResultSet from it, placing the new row in whatever visual position you prefer.

.. and, just to really emphasize it, even if you had a property to control what happens to updates to record that don't appear in cache, this would not solve the problem and you'd need to take the recommended approach anyway.