And so we return to finish the example from last time, the drag and drop educational scenario. As we left it, the basics were in place but there is still a fair amount of work to be done to finish the project and to make the whole process work as the user would expect. We will add some code on Remove Instance so that if the user removes a row from the left, we tidy up and remove the same row from the right-hand side as well.

In addition, we make some minor changes to the way the list on the right is displayed. We keep the “clone” of the row from the drag and drop, but we disable the inputs so that the user does not mistakenly think they can change the values in the list on the right.

In the same style, we change the click event of the “X” button on the dropped rows to remove the row from the right, and unselect the row on the left. And we can remove our ugly Remove button since we are just reusing the existing button, changing it’s behaviour:

Other changes are purely cosmetic – using a different row background color for example for the selected rows.

And of course we must not forget a most important part of the whole process – capturing the list of selected instances that are represented by the drag and drop. To do this, we use the “selected” flag and create a Reference Relationship based on that attribute. We can thus show the results in the final Screen for confirmation.

So what remains to be done? Well, beyond this simple educational example, there is obviously the need to be able to allow the user to move backwards as well as forwards. For example, the Screen, if navigated away and back again, will simply forget all about the selected rows. This is due in part to the fact that the demonstration uses an Entity Collect, so the entity instances on the left do not actually exist outside of the client until you click Next. But if you click Back, you find yourself with the rows on the left, but nothing on the right! Our process does not “redraw” the list of selected instances. Everything is available to let us do it, since we know which rows have been selected.

We canuse (in this demonstration) onNavigated to detect if the Screen is reached from a navigation, and if this is the case, we can rebuild the list of selected items – by finding the entity instances that are selected, and once again using clone() to copy them into the dropped area, and changing the colour / the behaviour of the remove button again. So the user does not have to drag and drop them again.

The final step will be to add a custom Footer, which will allow the page to be “redrawn” if the user (or the debugger) refreshes the page. This is needed because there is no onEvent that handles this sort of scenario. Dropping the code into a Footer extension is a cheap and dirty way to ensure that the rows are redrawn in a refresh.

Of course a lot of this will need to be encapsulated and properly cleaned up, but this is just for a bit of fun – it is also very ugly so you can bust out your CSS skills to improve that too. But now our drag and drop demonstration is complete.

You can watch the drag and drop walk-through below and get the Zip Archive if you want, using the link at the bottom of the post. We’ll be announcing some cool stuff around that later this year.

Have fun!

Get the Drag and Drop Zip Archive!