...

The workbench can get out of touch with reality after an action is performed on the content that it displays.

When deleting a node or a property the workbench must update its selection to not still think that the now deleted node or property is selected.

When renaming a node or a property the workbench must update its selection to not still think that the old name is what's selected.

The workbench must be able to support a node that has a child node and a property with the same name.

The actionbar and the statusbar must be synchronized to the selection of the workbench.

Container

We change the containers to identify the items within it not using their paths but instead in a format consisting of the node's identifier and the name of the property if it represents a property. We don't add a dedicated object for this, instead we use a string representation, to keep the memory footprint down.

The string representation is <uuid> for nodes and <uuid>@<propertyName> for properties.

Changing this will solve that we cannot distinguish between a child node and a property that has the same name. It will also make it easier to keep the selection in sync, although it will not be enough to completely fix the sync issues.

Actions

The workbench passes on the selected item to the action, if nothing is selected the passed on item is the node used as root for workbench (configured in WorkbenchDefinition.path).

...

• A node was added
• A property was added
• A property was removed
• A node was removed
• A node was renamed
• A node was moved
• A node and all its sub nodes had the activation status changed.
• The order of sub nodes was changed.
• More than one node was removed
• More than one property was added to a node
• Every sub node on a node got a new property
• Nothing changed
• A command was executed
• And there are many more examples...

Can the action be expected to know what changes a command made?

Workbench

After an action After any of these changes the workbench needs to show the workspace as it now is and update  update what item is now selected. Also, the actionbar and the statusbar must be updated based on the new selection.

When renaming a node or a property the workbench must update its selection to not still think that the old name is what's selected.

When the selection changes so must also the location.

Events

We're using events to synchronize the workbench after an action is executed. We will need to review the events, when they're sent, if they carry enough detail, and which bus they're sent on.

...

<to be verified: unwanted activation of drag & drop mode on ipad>

We will probably need an action for move, for two reasons, the ipad and due to the TreeTable not scrolling when you drag an item to the top or the bottom of the table.

Out of scope for this concept

...

Multi select and execution of action that operate on multiple items

Proposed solutions

1 Actions return list of changed or deleted paths

The returned list would contain paths dirtied by the operation. The list would be paths that have been deleted or updated, where updated means that there were changes made to the node itself, the order of its child nodes changed or larger changes made to the subtree below the node.

2 Actions fire detailed events about the changes made

The action would fire many events or a single event containing many dirtied paths (see above).

3 Bridging JCR observation events into the container

The container itself would be responsible for being in sync using a JCR observation listener to monitor changes. When something is changed the container updates its internal state and repaints its UI.

If necessary the events could be buffered and processed only on request after an action has been executed to limit the amount of repaints. Or buffered for a period of time in order to collect a bunch of events and repaint only once for all of them.

4 Actions use JCR observation to monitor all the changes made and fires events

Basically a combo of 2 and 3

Evaluating the proposals

For proposal 1 and 2 we assume that the action has the information of exactly what was changed. If the action executes a command we can't expect the action to have full knowledge about all the changes made.

For proposals 1, 2 and 3, when the list or the event(s) are processed by BrowserPresenter or WorkbenchPresenter, what do they do with the information? They can update the selection yes. But can they update the container properly? Won't calls to the container to remove an item also go through to the JCR attempting a new delete operation?