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.

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.

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.