Issues/51

[devintuffy]

PR for ticket #51

In this branch:

• Style updates for explorer: added drag handle, changed cursor to indicate dragging (please note that Chrome and Firefox don't support css changes to cursor during drag, but Safari works nicely), some other minor CSS tweaks

• Change in behavior of explorer navigation: clicking on an item name edits the item (if applicable), added folder icon to drill down into folder.

• (currently turned off) Folder sub-item count badge display to show users how many items are in a folder. We need to figure out the best way to display this number, right now I am showing them as overlay numbers on the folder, but that UX is more suited to 'new item' that can be cleared. To see this work, change the call to writeProperties on line 130 of NodesServlet.java from writeProperties(child, json, false) to writeProperties(child, json, true);

If we decide not to use the display count, I'll remove the code that counts children.

[reusr1]

I do like how it feels. I am not sure I like the count overlay - maybe a difference in the icon itself may work (eg show empty vs populated folder). I do also think if we need the child count we may be better off adding this functionality to the PerBase class and adapt the resource to it.

[devintuffy]

Further updates

• Added and implemented dblClickCommand to admin-components-action. If this is specified, we will manually count the timing of successive clicks and if two or more are fired within the timeframe we call the doubleClick action, otherwise the default. If no dblClickCommand is specified then we don't bother with any of that and just call model.command as usual.

• removed the child count code until we figure out the best way to fetch/display it

[devintuffy]

The doubleclick functionality leaves a slight delay before the editPage starts. That would be unavoidable, after a single click we need to wait a period of time (currently set to 200ms) to see if another click happens before proceeding with the action. In practice it feels like more than 200ms. I'll play with this a bit more, I don't really care for the experience as-is. Might just be a matter of timing adjustments.

Update after a little more experimenting: the additional delay I am noticing might be the editor opening, as the direct edit button (which doesn't have the doubleclick attached, so no delay) also has a slight pause.

We may want to add in a "loading" state for actions with a delay. Like a slightly opaque overlay with some simple progress animation? That would be for another ticket.