pagination in Editable Grid

As Naresh suggested already, this has been discussed many times in the past in previous posts here in Community, usually under the subject heading of "sorting" editable grids (for our purpses, sorting and pagination should be treated as essentially the same subject since they both involve the same principles and the same underlying functionality).

That being said, I just tried searching for past posts on the subject and I find that searching old posts seems to be broken at the moment.  I think someone may have mentioned this to me last week but I'd forgotten.  Ben Dudley / April Schuppel is this a known issue? (Sorry to keep bugging you two this morning).

Back to the subject at hand, though - as in the past, I strongly recommend against rushing into implementation of some bespoke editable-grid-pagination scheme, especially since it requires manual implemention and some pretty serious work-arounds to avoid overwriting already-changed data. It's doable but in my estimation, anyone familiar enough with manual SAIL development to do this safely, will also be familiar enough with it to do the implementation pretty much on their own.  This isn't meant as some sort of "gatekeeping", but more as an advisory of how difficult it can be (i usually don't even try to do it myself).  I usually suggest, instead, to have a read-only grid (with inherent paging) where a user can click some sort of "edit" link on an individual row, make and save changes to that row, then continue with other rows if they want.

As Naresh suggested already, this has been discussed many times in the past in previous posts here in Community, usually under the subject heading of "sorting" editable grids (for our purpses, sorting and pagination should be treated as essentially the same subject since they both involve the same principles and the same underlying functionality).

That being said, I just tried searching for past posts on the subject and I find that searching old posts seems to be broken at the moment.  I think someone may have mentioned this to me last week but I'd forgotten.  Ben Dudley / April Schuppel is this a known issue? (Sorry to keep bugging you two this morning).

Back to the subject at hand, though - as in the past, I strongly recommend against rushing into implementation of some bespoke editable-grid-pagination scheme, especially since it requires manual implemention and some pretty serious work-arounds to avoid overwriting already-changed data. It's doable but in my estimation, anyone familiar enough with manual SAIL development to do this safely, will also be familiar enough with it to do the implementation pretty much on their own.  This isn't meant as some sort of "gatekeeping", but more as an advisory of how difficult it can be (i usually don't even try to do it myself).  I usually suggest, instead, to have a read-only grid (with inherent paging) where a user can click some sort of "edit" link on an individual row, make and save changes to that row, then continue with other rows if they want.

Hi Mike,

I think it's worth a time to have a look at the solution I've proposed on this topic. It includes examples also.

I've created an interface that performs the pagination functionality which then you can use as a common component object in other interfaces under Grids. 

https://community.appian.com/discussions/f/new-to-appian/24424/pagination-in-editable-grid

In the sample code in that thread, unless I'm severely missing something, it looks like changes in editable grid rows are only saved into fv!item.[property] for the individual columns, which saves directly into the dataSubset, but not into the original source variable (in this case, local!employeeData).

The problem here is, any time any paging is executed, any changes entered on the current page would be lost because the value of local!dataSubset will be merely overwritten with the next page's values from the following "page" of the original data set.

Mike, That's actually one of my favorite patterns.  It would come across even better if Appian came with some cool screen transition animations, but alas.

The idea is that you hide the grid and show a small form (in a boxLayout or a card or something perhaps) with an obvious control to save or cancel your edits to the one row, and when you do, voila the changes are in the row in the grid when it reappears.  You do it with 2 mutually exclusive showWhen's on the sub-form and on the grid.  When one is showing the other is necessarily hiding.

The main benefit of this, of course, is that you get the paging grid's paging, sorting, filtering, searching, export to excel, and other features for free, and you don't have to deal with fat fingers as much, and you can customize the look and feel of your inputs with anything you want, even stuff that doesn't work on editable grids, all for just one extra click or two for the user.

Exactly.  And you don't have to implement some brain-melting, bespoke saveInto code hijinks to get the row-level changes to not be overwritten as soon as the user pages or sorts the grid.