Are Repeater Item Indexes persistent?

repeater-widget

#1

I need to sort a Repeater and then update each row in the sorted order. I had assumed that the Item.index for each row would change with the sort but this doesn’t seem to be true. Whatever the original order of the rows is those Item.indexes seem to be ‘stuck’ to their rows despite the sort order. This being the case I cannot think of a way in which I can process the table in its sorted order!

In the attached example, the repeater has 3 columns: Index, Data and Random. OnItemLoad sets ‘Index’ to Item.index. Try the following:

  1. Click UPDATE. This populates the RANDOM column with random number.

  2. Click APPLY SORT. This sorts the table by the values in RANDOM. Note that the Item.index values in the INDEX column seem to correspond to the sorted order.

  3. Select an option from the ‘Filter’ dropdown. This applies a filter ‘Item.index = selected option’ to the table.

You will see that, instead of showing the row which has that index number in the INDEX column, it shows the item whose ‘original’ index (i.e. before sorting) matches the selected option.

This suggests that the original indexes are persistent. If this is so, how can I step through the table in its sorted order to update each row according to its sorted position?

20181017 Repeater Sort Test.rp (64.0 KB)


#2

Hi fastnbulbous,

The reason why the sort does not stick is because each time you make a change to the repeater dataset (e.g. filter, sort, add/delete rows, etc.), the repeater is refreshed and does not retain the changes that were made to it previously.

I think I may have a bit of a Friday brain to think of the most efficient or logical way to build this (sorry!), but I found one solution is to create a second repeater, add rows from the original repeater to this duplicate repeater after the sort so that its original dataset is the one after the sort, and then filter/show this repeater instead. This should make it so that it appears as one dataset, but you’re actually filtering the second repeater that is retaining the sort information.

I’ve edited your file to demonstrate this. Hopefully it gets you closer to what you’re looking for!

20181017 Repeater Sort Test_EDIT.rp (68.6 KB)


#3

Thanks Jane, but perhaps I didn’t explain very clearly.

I understand that everything gets updated whenever a change is made. My point is that Item.index does NOT get changed even though it appears to be! In my example, after the sort is applied, the Item.index column reflects the new order. But then if you apply the filter to the Item.index it is the underlying, original Item.index that gets filtered NOT the one that is shown in the Item.index column. In other words, the original Item.index, the one that is set when the page is initially loaded, ‘sticks’ to that row throughout the session.


#4

I attach another example of this issue, where isFirst doesn’t behave as I would expect.

The repeater has four columns:

  1. Ref Num - sequential numbers 1-9
  2. Item.index - That row’s Item.index
  3. Data - just some arbitrary data
  4. Updated - shows whether a row has been updated

If you enter a character in the ‘Enter data’ column, the Data column will be changed for that row and the Updated cell will show ‘true’.

First time: change the data for 2-3 rows including the first row then click the sequence of buttons:

  1. Only those items where updated=true will be visible.
  2. Only the first item will show.
  3. The Updated column for that one item will be changed to ‘false’ and the item will disappear because the updated=true filter is still applied.
  4. The remaining items where Updated=true will show.
  5. All items show.

Throughout this sequence the Item.index column is updated to reflect the order only of those items that are visible.

Reload the page and repeat the sequence but do not include the first row in those you change. You will see that, although the Item.index column is still sequential from 1, when you apply the isFirst filter no rows are visible because isFirst appears to be applied to the underlying, original Item.index and not the one that results from filtering (or, in my previous sample file, from sorting).

Whether this is logical and consistent or not (or whether I am completely misunderstanding!!) my question is: How do I step through a filtered/sorted repeater row by row if I can’t use Item.index or isFirst to do it???

20181023 Persistent ItemIndex.rp (76.6 KB)


#5

Hi fastnbulbous,

Apologies for the delayed response!

I’ve been looking over your question about [[Item.index]], and while I don’t have a quick answer for you right now, we found a solution that will help a bit more than my original response. Since [[Item.index]] is still referencing the index of the original dataset, before the sort, what you can do is add a hidden column to the repeater that stores the index of the repeater after the sort. Then, rather than filtering by index, filter by that column instead.

I’ll be looking into this further next week with our teams, and will update you whether I find this is a bug or expected behavior where applying a filter using index still references the index of the original dataset.

In addition, you’re right that [[Item.isFirst]] still references the first item in the repeater, even after a filter or sort. The only time [[Item.isFirst]] changes its target is if you were to delete the first row. You will then see that [[item.isFirst]] will reference the next row after the first.

20181017 Repeater Sort Test_EDIT2.rp (66.1 KB)


#6

Thank you Jane.

That’s more-or-less the approach that I took in the end.

Underlying this though is my question about processing a repeater dataset row-by-row. For example, if I want to examine ColumnA in each row and, depending on its value, update ColumnB, is the only way to apply an iterative filter on the Index (Index=1, then Index=2 etc.)? This would obviously be visible to the user, so it implies always having a ‘shadow’ hidden Repeater that is used to update the visible one.


#7

Hi fastnbulbous,

I reached out to our QA team about this, and they’ve let me know that while they don’t have a clear explanation for why [[Item.index]] references the index of the original dataset, this is the way it’s behaved since Axure RP 7 and the way it works right now, but we could file a request for it to work how you expected with our respective teams.

And yep! I agree the best way to examine each column row-by-row would be to use [[Item.index]]. Whether or not you need a second repeater would depend on the structure of your file and the functionality you’re going for, but lmk if you want another pair of eyes on the best way to accomplish that.


#8

Thanks for your help on this Jane. I don’t think it’s a very useful situation and it would be more logical to change how the Index works but I guess we’ll just have to work around it for now!!


#9

Incidentally I have come across what I think is another anomaly which I’ve submitted here: Condition is not triggering correctly