[edulid]

1. have you checked whether the newly added row is now in the cache, but not visible in the grid viewport? You can just search the dataset via ResultSet.find()

You are right: the newly added row is found via ResultSet.find(). Nevertheless, I cannot see it in the listGrid.

2. the behavior you're hoping for is actually not specified (the docs don't cover what's supposed to happen when an "update" results in a newly added row), and it's not clear, from a design perspective, whether it's actually desirable for a *related update* which did not involve any end user input, to suddenly pop into view.

Ok, I understand. But, the other way around, when the row is being deleted from the listGrid because of an update, the row is really deleted. So is this not an inconsistency? With your words:

Case A: A *related update* , which did not involve any end user input, suddenly is being DELETED from the listgrid.

vs

Case B: A *related update* , which did not involve any end user input, suddenly is being ADDED to the listgrid.

So why is case A happening, while case B is NOT happening? I see an inconsistency here.

Another inconsistency:
When the relatedUpdate is an add-operation, I immediately see the newly added record in the listGrid: I see the new record at the beginning of the listGrid. So, again, we have an inconsistency here:
For the listGrid, although really an update, the action is an add:
11:36:49.678:XRP4:DEBUG:ResultSet:isc_ResultSet_0 (created by: isc_ListGrid_0):updated cache: 1 row(s) added, 0 row(s) updated, 0 row(s) removed.

So, different than a "real add operation", this listGrid's add operation is NOT being shown immediately in the listGrid, while a *real* add operation is. So, again, this is an inconsistency.

If you prefer to do this somewhere more ListGrid-specific, there's also the DataChanged event on ResultSet, which would actually fire for every data update that actually affects that specific ListGrid. Note this would fire for adds and deletions too, but you could keep track of the ResultSet.getLength() to be able to tell the difference.

This is very strange, because this is NOT happening at my test case. Here I have a small change to the MyWindow3.java:

public class MyWindow3 extends Window {

	private final ListGrid lg;

	private final IButton switchButton;

	private Integer actualStatus = 1;

	TextItem idItem;

	public MyWindow3() {
		setWidth(600);
		setHeight(500);
		setAutoCenter(true);
		setIsModal(true);
		setShowModalMask(true);
		setShowMaximizeButton(true);

		VLayout vlayout = new VLayout(12);
		vlayout.setPadding(25);

		lg = new ListGrid();
		lg.setDataSource(DataSource.get("testDatasource"));

		lg.setWidth100();
		lg.setHeight100();
		lg.setSortField("f_id");
		
		lg.setAutoFetchData(false);

		HLayout buttonsLayout = new HLayout(15);
		buttonsLayout.setHeight(25);
		buttonsLayout.setAlign(Alignment.LEFT);

		DynamicForm df = new DynamicForm();
		idItem = new TextItem("id");
		idItem.setWidth(40);
		df.setColWidths(40,40);
		df.setFields(idItem);

		buttonsLayout.addMember(df);

		switchButton = new IButton("Switch status");
		switchButton.setWidth(200);
		switchButton.addClickHandler(new ClickHandler() {
			@Override
			public void onClick(ClickEvent event) {
				onSwitchButtonClick();
			}
		});
		
		IButton resultSetButton = new IButton("Get resultset length");
		resultSetButton.setWidth(200);
		resultSetButton.addClickHandler(new ClickHandler() {
			
			@Override
			public void onClick(ClickEvent event) {
				SC.say("getResultSet().getLength() = " + lg.getResultSet().getLength());
			}
		});

		buttonsLayout.addMember(switchButton);
		buttonsLayout.addMember(resultSetButton);
		
		IButton findButton = new IButton("Find 511");
		findButton.addClickHandler(new ClickHandler() {
			
			@Override
			public void onClick(ClickEvent event) {
				Record rec = lg.getResultSet().find("f_id", 511);
				if (rec == null) {
					SC.say("Not found");
				} else {
					SC.say("Found: " + rec.getAttribute("f_id"));
				}
			}
		});

		vlayout.addMember(lg);
		vlayout.addMember(findButton);

		Criteria c = new Criteria();
		c.addCriteria("f_vertrag_status", 1);
		lg.fetchData(c, new DSCallback() {
			
			@Override
			public void execute(DSResponse dsResponse, Object data, DSRequest dsRequest) {
				lg.getResultSet().addDataArrivedHandler(new DataArrivedHandler() {
					
					@Override
					public void onDataArrived(DataArrivedEvent event) {
						SC.say("Data arrived");
					}
				});
			}
		});

		vlayout.addMember(buttonsLayout);

		addItem(vlayout);

	}

	private void onSwitchButtonClick() {
		Record updateRec = new Record();
		updateRec.setAttribute("f_id",
				Integer.parseInt(idItem.getValueAsString()));
		Integer newStatus = null;
		if (actualStatus.intValue() == 1) {
			newStatus = 3;
		} else {
			newStatus = 1;
		}
		updateRec.setAttribute("f_vertrag_status", newStatus);
		actualStatus = newStatus;
		DataSource.get("vertraege").updateData(updateRec, new DSCallback() {

			@Override
			public void execute(DSResponse dsResponse, Object data,
					DSRequest dsRequest) {
				//SC.say("OK");
			}
		});
	}

}

The event

public void onDataArrived(DataArrivedEvent event) {
						SC.say("Data arrived");
					}

is NEVER being fired. If I push the "switch" button, the callback is NOT being called, which is not correct. or? I suppose that this happens because the row "never arrives".
Example:
1) Assume f_id=511, f_vertrag_status=1 is shown in the listGrid.
2) Write 511 in the textField and push "switch".
3) The row f_id=511 disappears, which is correct, because its new values do not match the actual listGrid's criteria (the new f_vertrag_status = 3).
--> No data arrives, because it is already here!! So the event is not firing.
4) Push "switch" again.
5) The row f_id=511 is NOT appearing. The event is NOT firing. Why not ?

[Isomorphic]

Case A: A *related update* , which did not involve any end user input, suddenly is being DELETED from the listgrid.

This is clearly the right thing to do, since any user interaction with that deleted record would be futile.

Case B: A *related update* , which did not involve any end user input, suddenly is being ADDED from the listgrid.

Here we don't have enough context to have a behavior that will clearly be correct in all situations. But the default behavior of bringing the record to the attention of the user seems more often correct than not.

So why is case A happening, while case B is NOT happening?

We are talking about a record that the user has never loaded and has never interacted with. It does not seem like a good default behavior to force it to be the single most visible record on the screen.

Note that in general, the word "inconsistency" is inapplicable here as we are talking about very different situations.

We've provided an approach to get the particular behavior you want; if you'd prefer something like framework flags that would make it possible to just configure the framework to provide that behavior by default, that's a possible Feature Sponsorship, but at this point we don't see anything that could be called a bug here; instead what we have are default behaviors that are reasonable and some different behaviors you appear to want for your app.

The event .. onDataArrived ..

We suggested DataChanged on ResultSet. DataArrived is not the event we suggested, and would not be expected to fire in this circumstance.

Note for completeness that the suggestion to use DataChanged was actually from another thread.

[edulid]

But the default behavior of bringing the record to the attention of the user seems more often correct than not.

This supposely default behavior of bringing the record to the attention of the user is NOT happening, although you say that this behavior seems more often correct than not.
If the framework was bringing the added record to the attention of the user, this thread wouldn't be necessary, since this is the behavior I'm trying to achieve :)

Since the record is not being added to the listGrid, the framework is NOT bringing the record to the attention of the user. Or did I misunderstand your statement?

We've provided an approach to get the particular behavior you want.

Do you mean "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." ?
Yes, I will take a look at this approach.

[Isomorphic]

You are sending a relatedUpdate with an "update" operationType performed on a record that has never been loaded by this user. This happens to require adding the record to the dataset because this is a partially loaded data set and the record in question has never been loaded by this particular user.

This is not the same as an "add" of an entirely new record, which would be indicated by operationType:"add".

It could be argued that not every "add" performed by as a relatedUpdate should result in popping to the top of a databound grid - perhaps it actually should not if it's a relatedUpdate as opposed to an action that was actually initiated by the current user.

But it seems clear that with operationType "update" in a related update, it does not make sense to pop the record to the top of all databound grids as a default behavior.

[edulid]

For completeness:

I'd expect this to work, too.

But it doesn't and seems it won't without a workaround: http://forums.smartclient.com/showpo...6&postcount=19

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

[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

[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

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

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

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?

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

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]

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?

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