It should work for any number of items.
Both brilliant solutions!
But what if the current RG (the one the user is re-arranging) is a filtered list, does it make sense to use the cell âindexâ # as a reference? shouldnât it use rather the items actual ranking in the DB?
And wouldnât this modify the ranking of items that shouldnât be touched (filtered items).
And for @gbenchanoch what if this RG presents directly a list of things, (not a thingâs fieldâs list of things)
Do you mean a âsearch forâ? That would be a simpler workflow since you donât need to save anything to the DB. You can use the same logic and just display the new merged list in the repeating group. Iâll add that as a separate RG in the demo app once I have time.
But i DO want to save that new order, next time the user loads his page again
If itâs a full list of things, this is possible by adding a rank data field and utilizing a modified workflow. For filtered lists you would not be able to do this since the data youâre working with would have missing data without the ability to reference the locations of those missing data. You could potentially save duplicates of the lists in a new âListâ custom data âthingâ
What exactly is your use case?
Okay - I managed to solve your use case in two ways:
-
Uses backend workflows but is disabled in the editor since I would need to upgrade the app.
-
Uses a global Javacsript function and a Javascript event. The global function, updateRank(), is defined on page load and will trigger a Javascript to Bubble Event to update the rank of a âSportâ in the database. Each time you drag and drop, a Javascript loop is triggered and iterates from numbers i = 1 to i = length of list. Each iteration of the loop triggers the function updateRank() which triggers the Javascript to Bubble Event which actually writes the new rank to the database. This workaround is just a replication of what I did on the back end, just on the front end. This required a short pause (which you will notice as the rank # updates in the UI) to allow for the list to be ready before the Javascript loop is run. Iâm very tired so sorry for the terrible explanation. The cool thing is that, since it is using states, the UI doesnât experience the delay unless you literally display the rank. Even if you act very quickly to sort, the last loop will update the ranks properly, even if the previous loops havenât finished.
I left the original list as well so that you have both examples. They are organized in separate folders (workflows). The list that is contained inside another object is in the folder âContainerâ while the full list is in the folder âFull Listâ
Edit: I added the workflows to ensure that adding a new âSportâ sets the rank properly and deleting a âSportâ updates the ranks.
Edit2: I know it seems redundant to trigger a JavaScript function from the loop that then triggers the JavaScript to bubble function. I tried triggering the JavaScript to bubble function directly from the loop and it wasnât working so this was my next idea. Works so meh, at least itâs a proof of concept. Iâd probably use the backend version for simplicity
Edit3: Front end workaround using JS doesnât seem to work on mobile. Seems to be a weird bug either with drag/drop or with repeating groups on mobile @nick.carroll. Oh well, the backend version will.
Thanks will check it out
It seems that the bug Iâm seeing in mobile is happening on your plugin as well. No sure what the plugin code is but thought youâd be interested to check out the mobile issues.
Yeah I see that now. I hadnât checked mobile. Thank you for pointing that out. Iâll take a look.
Thanks, will test soon
If you are seeing the bug in the method you are using, does your method run on a loop and use one workflow multiple times, once for each item in the list separately or is it one action running once on a list?
Iâm seeing the bug when trying to update a ârankâ data field. I have two methods, but only one is live on my demo since you canât use backend workflows without upgrading the application. I donât think that the backend workflow will have any issues.
The frontend workaround I set up uses a JavaScript function to loop through each of the repeating group items and overwrite the rank. This triggers a BubbleToJavaScript event multiple times, once for each item in the list. I imagine youâre doing something somewhat similar in the plugin code.
@duke.severn put together this brilliant âmostlyâ native solution:
Yea thatâs exactly what Iâm doing in the code. I wonder why using that method on mobile causes an error. I have used this method in one other plugin but then I used a setTimeout of 100 milliseconds on each iteration and it works fine on mobile. Maybe that is the solution to the bug. Iâll have to test it out.
@duke.severn
Using this method, there is a problem when adding a new entry to the database after re-ordering the list, (while using the standard âorderâ field expression: âorder-numberâ=items:count+1).
This will not always put the new item as the highest rank