Get all changed rows from a grouped listgrid

[BenediktK]

Hey guys,

I just built a listgrid which allows grouping. The listgrid further has disabled “autoSaveEdits”. Next to it I implemented a save button, which shall save all edits when pressed by the user.

The problem here is, when groupBy is active and the user changes some fields, the method listGrid.getAllEditRows() will answer an empty Array, instead of all changed rows / records.

The following gif shows a scenario like that:
1. Pressing the changedRowsButton
=> No changes
2. Start editing of the first row and press button
=> The changed rows includes the editing row
3. End editing by pressing “Return” and press the button
=> The changed rows doesn’t include the changed row anymore, but it doesn’t get saved meanwhile
4. Ungroup the listgrid and press the button
=> The changed rows again includes the changed row, so it seems to recognize the changed row



The follgowing gif starts shows the other way round, starting with an ungrouped listgrid
1. Pressing the changedRowsButton
=> No changes
2. Start editing the first row and press the button
=> The changed rows includes the editing row
3. End editing by pressing “Return” and press the button
=> The changed rows still includes the changed row contrary to the grouped list grid
4. Group the listgrid by name and press the button
=> The changed rows still includes the changed row
5. Collapse group of the changed row and press button
=> Changed rows are empty, but there is still the hidden changed row



To save all changes, I need a method to get all changed records. For regular listgrids I can use the listGrid.getAllEditRows() and afterwards search for these rows with listGrid.getRecord(). But when working with a grouped listGrid, this won’t work anymore.

So is there a way to get all changed records, regardless whether grouping is active or not?

This issue is reproducable in all current browsers (Chrome, Firefox & IE) and your latest nightly build SmartClient_v10.0p_2015-03-09.

Best Regards

[Isomorphic]

Sorry for the slight delay responding here. This is under investigation and we'll follow up when we have more information

Regards
Isomorphic Software

[Isomorphic]

We've made a change to address this for tomorrow's build.

If you still see issues, please show the code for your sample.

[BenediktK]

Hey guys,

I’m still having the same Issues, when testing with your nightly build from 19th May 2015 (v10.0p_2015-03-19).

When changing the given data and pressing enter, there will be no changed rows returned by getAllEditRows(). The following gif show this scenario in the provided example.



I forgot to post my code last time, sorry.
Following the code example for reproducing the issue

isc.ListGrid.create({
	"ID" : "listGrid",
	"width" : 150,
	"height" : "15%",
	"canEdit" : true,
	"autoSaveEdits" : false,
	"fields" :
	[{
			"name" : "uniqueID",
			"hidden" : true
		}, {
			"name" : "name"
		}
	],
	"groupByField" : "name",
	"data" : [{
			"uniqueID" : 1,
			"name" : "One"
		}
	]
});
isc.DynamicForm.create({
	"ID" : "form",
	"left" : 5,
	"top" : "15%",
	fields : [{
			"name" : "changedRowsTextItem",
			"title" : "Changed rows",
			"width" : 100,
			"canEdit" : false
		}
	]
});
isc.Button.create({
	"title" : "Show changed rows",
	"left" : 5,
	"top" : "19%",
	"width" : 150,
	"action" : function () {
		var changedRows = listGrid.getAllEditRows();
		var textItem = form.getField("changedRowsTextItem");
		if (changedRows.size() == 0) {
			textItem.setValue("None")
		} else {
			textItem.setValue(changedRows)
		};
	}
})

Best Regards

[Isomorphic]

We'll take another look

[Isomorphic]

A quick note that we do indeed see this issue with your test case - the problem arises because the grid is not databound and, in such circumstances, we use the values of the record as an identifier - we're looking into the best way to deal with it.

In the meantime, you can address your issue by assigning your records as the cacheData of a new clientOnly: true dataSource, and setting that as grid.dataSource, rather than setting grid.data.

[BenediktK]

Hey guys,

are there any news?

Wouldn’t returning records instead of row numbers solve your listed issues?
Further, most of the time asking for changed rows, there is only a need for the changed records - e. g. to get all changes and save these. So if you could provide an alternative method like “getAllEditRecords()” this would solve the problem of hidden changed rows in a groupTree where you can’t return valid row numbers, because they’re not visible. Also searching for the changed records could be dropped, because you already got it.

This solution would also work the other way round when having a changed record and e. g. needing so set an error to it like in another thread of mine.

Thanks for your response.

Best Regards

[Isomorphic]

Hi BenediktK
We're still looking at whether there's a good framework change for the issue here, but the approach of using a clientOnly dataSource is the correct solution for now.

(Using rowNumbers to track edits isn't really an option for various reasons we can't really explains without getting into the internals of how the edit-values subsystem works)

On the other thread, the suggested approach of explicitly opening the parent is our recommended solution. Since you're raising it again, we'll follow up there with a little more detail shortly.

Regards
Isomorphic Software

[BenediktK]

Hey guys,

thanks for your reply to my mentioned post. I’m happy with the workaround with opening the parent node and afterwards setting a field error for a hidden record and thus don’t need an extra feature.

Back on topic.
The approach of using a clientOnly dataSource would cause huge changes on our framework, which is why this approach is not feasible.
Is there a solution besides the clientOnly dataSource - which only seems to be a workaround - in sight?

Thanks for your response.

Best regards

[Isomorphic]

Using a clientOnly dataSource isn't really a workaround - it's a good approach for manipulating data at the client-side, particularly if complex features like sorting or grouping/totalling are required.

What are the "huge changes" you envisage by using a clientOnly dataSource? You need only define a DS with some fields (and a PK-field of some sort), add the data array you already have as the cacheData of that DS and then assign the DS to the grid.

That said, we *are* taking a look at what can be done about this (retaining an edit session for a grouped record when its group-value changes and there's no PK, because data is an array), and we'll update here when we have more information about that.

[BenediktK]

Hi,

the huge changes for us would be that the client-only datasource is not yet implemented, because there was no need for it.
By now we use only datasources if we are displaying many items in a listgrid (or treegrid). We think that this is the best usecase. Working with listgrids without initiallly have to set all displayed data. Imho: If there are only 10 items, neither a local nor a server-datasource should be needed.

Sorry for asking, but is there any kind of news about a fix for this issue without client-side datasource?

Thanks for your response

Best Regards

[Isomorphic]

Seriously, the clientOnly dataSource for this scenario is very, very simple - maybe a handful of lines, just assigning fields and cacheData, both of which you are already assigning in some form, as fields and records in the grid directly. And as we said, for now, a clientOnly DS is the correct way forward.

The underlying issue *is* queued, and we'll get to it soon - but your use-case is quite unusual. You have a grouped grid with array-based data (so, no primary key), and changes are not being saved to the array right away. But you are also showing the groupField in the grid, and allowing it to be edited. That alters the group in which the record lives and causes it to be regrouped, which process currently relies on live record values, not their unsaved edit values.

Depending on the complexity involved in addressing this, it may need to be implemented as a Feature Sponsorship - but we'll update here when we know.