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

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

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

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.

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

[Isomorphic]

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.

[edulid]

Another simple testcase in terms of your showcase, maybe this helps you to understand my real usecase:

You have a listGrid which is always open. It shows all "Tree" showcase-examples, i.e. having criteria: type="Tree".

You permit the user to change the type of the showcase-examples in a dynamicForm.
So a user changes the type of a record to type="Layouts". It disappears from the listGrid, and the user is happy.

Then, he sees that it was a mistake to change the type, so the user changes the type again to the original type="Tree", and expects to see this showcase example in the listGrid of the "Tree" examples.

---> He calls you and asks you why this is not happening, why he can't see the "Tree"-record in the "Tree"-ListGrid.
Would you really tell him, he has to refresh the listGrid using invalidateCache(), since this is not the default behavior ?
You would have to put a "Refresh" Button, which invalidatesCache(), which is not recommended. So what to do with the perplexed user?

[edulid]

In the absence of any kind of argument that the framework is doing something inappropriate, this is just another instance of an application needing to have some code in it to handle things in a way that isn't a good default behavior.

No arguments ? See please my last post, and just run my code (have you run it?) :
Click the button "switch" 2 times: Do you really think that an end-user will think this is the "normal" behavior ?

I don't want you to change the DEFAULT behavior, of course not, but to have the OPTION to change this behavior for a specific listgrid, since we have all pieces of information for letting this option be changed!
The listGrid KNOWS it will add a record to the ResultSet, and the behavior is already implemented ! ( the behavior of an add-operation). The only thing needed is to connect these two pieces of information into an optional behavior.

[edulid]

For perspective, please understand that this is the only time someone has perceived and reported this behavior as a bug, even though the behavior has existed about 8 years unchanged.

But in my easy-to-understand testcase, let's say it is a usercase , where you switch between a criteria value and another, it is really not understandable for the end-user why one direction "works" (disappears from the listGrid), and the other direction does not work (does not show up in the listGrid).

The user perceives what he sees. So he doesn't know if the record is in the cache or not... so the user of my testcase says:
"why is the record not appearing in the listgrid, although it should"?

--> the user thinks this is a bug, and calls me, the developer. I have to explain the user that this is not a bug, but a "feature" of the framework used. And that there is not option to change this behavior.

My test case is really easy to understand, so I don't think this tries to achieve an "obscure" behavior.

I have a simple listgrid which shows some filtered values. If the user decides to change the value of one record, it disappears. If the user changes it again, it does not appear anywhere, and there is nothing he can do to make it appear again, but a refetch() or invalidateCache(), which is not recommended by isomorphic.

So the end-user calls me, and says he sees a bug in the listGrid.

This is actually not a fictional scenario: I have received many calls from users thinking this is a bug in my application. That's why I am trying to "correct it".

[edulid]

Exact !!!!! Such option would be perfect.

And I am not sure why this not easily achieved, since the information is already there:
:isc_ResultSet_0 (created by: isc_ListGrid_0):updated cache: 1 row(s) added, 0 row(s) updated, 0 row(s) removed.

So, the resultSet knows 1 row is being added. Why not have an option for having this added row *really, visually* added to the listgrid, i.e. the add-operation behavior?

This information is already there, the required behavior is already implemented, so what is the problem here?

[Isomorphic]

No one seems to be arguing either that the default behavior of the framework is the wrong one in terms of usability, or that it's wrong in terms of the docs. We'd be open to hearing either kind of argument.

Bear in mind that Blama's comment was about a log seeming to claim that the record had been added to cache. As we've established, that log was correct.

In the absence of any kind of argument that the framework is doing something inappropriate, this is just another instance of an application needing to have some code in it to handle things in a way that isn't a good default behavior.

For perspective, please understand that this is the only time someone has perceived and reported this behavior as a bug, even though the behavior has existed about 8 years unchanged.

[edulid]

Ok, good to know.

I understand "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.", but sadly this requires extra code.

From Isomorphic's other comments I get that this should work too:
1) If the client does not have the data yet, send the relatedUpdate as ADD.
2) If the client does have a record for that PK already, send the relatedUpdate as UPDATE.

I don't know edulids usecase, but if both is possible, that server needs to have some state information of the client which is definitely not wanted.

Exactly!!!! That's what I am trying to say. And I am not sure if the new ResultSet will still be "connected" with the original DataSource, and if everything works as before "disconnecting". I will try to test this workaround.

Without thinking too much about it (and not knowing the exact default behaviour) an alternative would be a new ListGrid setting "setAlwaysShowRelatedecords()", that, when enabled, basically does what Isomorphic described in "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.".

Exact !!!!! Such option would be perfect.

I think it was on purpose as information for me.

Best regards,
Blama

Yes it was.

[Blama]

You actually just linked to the last post from Isomorphic, which didn't seem to make much sense to link to - did you mean to link to something else?

I think it was on purpose as information for me.

Best regards,
Blama

[Blama]

Ok, good to know.

I understand "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.", but sadly this requires extra code.

From Isomorphic's other comments I get that this should work too:
1) If the client does not have the data yet, send the relatedUpdate as ADD.
2) If the client does have a record for that PK already, send the relatedUpdate as UPDATE.

I don't know edulids usecase, but if both is possible, that server needs to have some state information of the client which is definitely not wanted.

Without thinking too much about it (and not knowing the exact default behaviour) an alternative would be a new ListGrid setting "setAlwaysShowRelatedecords()", that, when enabled, basically does what Isomorphic described in "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.".

Best regards,
Blama

[Isomorphic]

You actually just linked to the last post from Isomorphic, which didn't seem to make much sense to link to - did you mean to link to something else?