With pagination or sort, losing data saved in inline edited rows

repeater-widget
advanced-prototyping

#1

When I enter a new row and I submit data to the cells in the row (the new row is on the second page), I see new values in the row and I can sort on the rows fine, except for when I add a new row. Now when I use paging, and page to the 3rd page and then return to the second page, the data I entered is gone. How do I persist the values entered? I am sure if it was one row, I could store the values in a VAR but what if there are more than 2 or 3? How is everyone else managing to keep their data with the paging set of tools within Axure?


#2

I think pagination is treated as a redraw of the entire repeater, so any data entered will be lost. You will need to use an ‘update rows’ interaction to change the underlying value so that when the repeater is redrawn the new value is displayed.


#3

Does anyone know for sure how to persist newly entered/changed/updated repeater row values with pagination or sort? I agree there is a redraw of the entire repeater. I REALLY need to keep the values when I add a new row, or multiple rows, or if I click the previous page button or the next page button, or if I sort on a page where the edits have been entered. Basically I need to keep all the changed/updated values if ANY redraw of the repeater occurs. I am concerned that if I have multiple values I have updated or that need to be saved, if I switch pages, or add a new row, or do a sort on the page and the values are not at least saved into local variables (which can get way out of hand if there are multiple row edits) what is the preferred mechanism to store the values on edit or on redraw of the repeater?


#4

Nobody is able to offer a solution? How do others who are using a grid/table/repeater with inline-editing keep their row values when they use pagination or sort on items in the grid?

This is a file I created for testing this issue. It has inline editing, a repeater in a DP, a drop list in a repeater, checkboxes, icons for Save/Edit/Cancel, cell notification on edit, sorting and pagination, as well as a paging footer that works with the last item in the grid to keep the control below the last item. This is a compilation of many ideas that have been posted on this forum. THANKS everyone for at least getting me to here:

InlineEditSortPaginate-PW.rp (118.1 KB)


#5

@davegoodman offered a good solution, and the only one I know of: update the repeater datasheet (the values for the columns in your repeater rows) in order to make them persistent. So, in your example file you have a “default” and “edit” mode for each row. When the “save icon” is clicked, rather than setting the text on widgets in the default state directly, you should use an Update Rows action to update the datasheet values. This will cause the table to reload, showing the updated values. Because the data is in the repeater datasheet and not just in the (repeated) widgets, it will be retained when you change repeater-pages, hide/unhide rows, update other rows, etc.

it is important to note that as soon as you navigate away from your (web prototype) page in the browser, all this data will be lost. Each time to load a prototype page, its default state will be created. If you need to track what data is in your repeater across different prototype pages, then you will need to devise a scheme to represent it in global variable(s). Take a look at this thread for more info:


#6

Thanks, mbc66… I will look closer at what I am doing and use the Update Rows action to update my datasheet values. I am sure that will help with keeping my values while the user is on the page, sorting or paginating. The big thing I am hoping to accomplish is the ability to keep my data persisted while the user is on the page and the repeater redraws, after adding a new value or values. I am seeing that if the data is in the datasheet it never goes away, even with sorting or paginating. I was just not completely aware that I needed to use Update Rows to alter the values in the datasheet. I was thinking that Update Rows was just updating the row in the repeater, not the datasheet. So updating the datasheet looks like the best plan.


#7

You’re very close. If you use ‘set text’ actions to change the contents of the widgets inside a given row or row state, then all that does is change the state until the next repeater refresh, at which point the datasheet is used as the canonical state. The Update Row interaction allows you to make changes to the datasheet itself, which acts as essentially a tiny fake database for your repeater.

You can also update multiple rows at once, using rules within the Update Rows interaction or using the ‘Mark Rows’ and ‘Unmark Rows’ functions. Repeaters can do some really wild things once you understand the basics of how to update them. Unfortunately the documentation isn’t very detailed, so a lot of it has to be gleaned by picking apart example files from the forums. And reading every post from @mbc66 :slight_smile:


#8

I have seen the place where I could add a rule, but I am not sure of the correct way to write one. Does anyone have an example of a ‘rule’ I might be able to use or how to create a proper syntax for a ‘rule’ to use?


#9

You can find the component parts of Axure rules in the Maths, Functions and Expressions documentation, but the detail of how to actually use a lot of this is very skimpy.

Most of what I have learned has been from searching for similar use-cases in the forums and dissecting the rules other users have written, which I appreciate is less than ideal.


#10

Thanks for the reply Dave, but I was really hoping just for a simple example. I guess I can look like you at others.


#11

There’s a good example of marking and updating a row included in the RP file in this thread.