Approach to editing a ListGridRecord's hidden fields

[bbruyn]

I have a datasource with a handful of fields on it. I need to display records from this datasource in a grid, and allow them to be edited somehow.

* The grid sets autoSaveEdits(false) and pending changes are instead saved via saveAllEdits using an RPCManager queue.

* Changes to any row's data should be saved in the grid 'automatically' (without the user needing to click some save/apply button at each row)

* Only a subset of the fields are to be shown in the grid, but I need to display/edit all of them when some record is selected. For what it's worth, one of the fields contains a chunk of html that I need to edit with a (custom) rich text editor. It's a bit unwieldy to display that editor in a grid cell with the other data.

I've experimented with a couple of approaches, including record expansion, master/detail forms, and record components.

Record components might work, except that I only want the html editor visible on row edit.

Record expansion is okay, except that I can't expand the record until a row has been saved.

AFAICS, master/detail forms are probably where I'll need to end up, except that I can't figure a good way to 'automatically' put a new row into the grid without actually committing the data. Again, I only wanted it queued up in the grid to be saved later.

So what I'm looking for right now is a confirmation/recommendation on which API/approach is the best fit here - if I'm on the right track with master detail forms, I'll follow up with specifics around the problem I'm having with it...

Thanks as always.

[Isomorphic]

It sounds like you already realize that if you edit with an expansion form or form entirely outside the grid, you can use setEditValues() to take changes from that external form and apply them to the grid, so they'll be saved when you call saveAllEdits().

Beyond that, as you pointed out, unsaved rows are special and have limited behaviors. There are two ways around this if you need an unsaved row to be fully functional:

1. save the row, and have the server acknowledge the save normally, but not actually persist to the database. When the ListGrid ultimately saves the row it will think it is doing an "update" and your code will need to realize it's really an "add"

2. use a clientOnly DataSource and have the grid save all changes immediately - you will then need to traverse the data in the clientOnly DataSource and issue your own series of "add" and "update" dsRequests based on the changes you detect.

As far as a best pattern for this - there really isn't a single best pattern. The decision revolves around the number of fields in the record, how important it is to keep the grid on the screen while editing of other fields occurs, etc.

[bbruyn]

I was able to have the 'automatic apply' requirement relaxed for new records, so I think I have a way (which feels like a hack, but it works) to get new records into the grid without resorting to either of the methods outlined below.

The last problem I have, I think, is applying a 'Selected' style to a new, unsaved record when the user clicks on it. Is there any way to make that happen without the workarounds you've provided?

[Isomorphic]

Unfortunately selection is limited for unsaved records for the same reason as the other behaviors: no primary key available. The two approaches mentioned below may be cleaner that the approach you're currently taking (since you described it as a hack).

[bbruyn]

Maybe, but all I want to do now is apply a style to the row at some index. I don't need a key for that, do I?

[Isomorphic]

In order to track the selection, the system uses the primaryKey as an identifier for the record. To support selection for an unsaved record that has no primary key value, we would need to upgrade the approach so that it could use some kind of special extra identifier for unsaved records, and even then, there would necessarily be special cases even in user code, since there's no Record per se.

So, if you need pretty much uniform behavior between saved and unsaved records, it's best to represent the record to the system as saved via the approaches mentioned previously. They are less complex then they might appear.