Swap two rows in readable grid

EREN_YEAGER said:

why using fv!item in the remove function ?

i agree, there are several things wrong here - it seems like "fv!row" has been incorrectly swapped out with "fv!item" in one specific instance in the screenshot, but even with all "fv!row" references, i'm not sure this will accomplish what AK is hoping to accomplish, since the save operation is being done on "fv!row" in general, which of course isn't the original array at all but instead only represents a pointer to a particular row in the supplied "data" dataset.  So I'm not really sure what the screenshotted code is hoping to accomplish.

why using fv!item in the remove function ?

Hi, I am trying to implement the same logic with record type as a data for grid. Could you check the below and let me know here where am i making mistake

and this reordering should save in db with different column

I've just tested it, and it worked exactly as you explained. I wasn't aware that fv!identifier gives the primary key when we are querying only current page's data . Thanks a lot, Harshit Bumb (Appyzie) . I've learned something new.

EREN_YEAGER said:

As far as I understand, fv!identifier seems to align its own sequence (1, 2, 3, 4, ...) in the grid

GridField is designed to work in 2 ways. 

1. Get all the data in local variables and just show some of it in the grid. Here the paging happens on the interface level and fv!identifier's output becomes uncertain. (like you have done in the screenshot you attached)
2. Get only a page's data from the DB and let the grid automatically query the next page, directly from the DB. In this approach, you pass directly the entire data subset in the grid. Once the grid displays data using the data subset, it will give primary keys when fv!identifier is referenced. 

So it depends on case to case but because fv!identifier's behavior isn't 100% same every time you pass just the Data and NOT Subset, I prefer passing the entire fv!row in the whereContains. 

And anyway, using a read-only grid and rearranging the rows isn't a good option. Because this grid isn't made for that, even if somehow it supports that. 

Harshit Bumb (Appyzie) said:

If you play with the identifier, you will need to make sure that everything in the DB also gets updated instantly to reflect on the screen

i think this is an important factor that needs to be drilled down into WAY more with OP prior to recommending any particular approaches here, since we don't really know what their desired end-effect is for the data in question.

I was wondering about the role of the primary key in this context. As far as I understand, fv!identifier seems to align its own sequence (1, 2, 3, 4, ...) in the grid. Please correct me if I'm mistaken. I appreciate your clarification on this matter.

I solved the problem by own. This is the logic which I was required.

a!gridColumn(
label: "",
value: a!richTextDisplayField(
value: a!richTextIcon(
icon: "arrow-down",
caption: "Move down",
link: a!dynamicLink(
saveInto: {
a!save(fv!currentPage.data[fv!identifier],fv!currentPage.data[fv!identifier+1]),
a!save(fv!currentPage.data[fv!identifier+1],fv!row),
},

),
showWhen: fv!currentPage.startIndex
)
)
)

If you play with the identifier, you will need to make sure that everything in the DB also gets updated instantly to reflect on the screen. But this comes with its own challenge. What do you think will happen with the Primary keys? How will you change the order of these rows in the DB keeping the same primary keys?