Story
Abstract
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.
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).
The impact of an action on the workspace can be anything from:
- 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
- And there are many more examples...
After any of these changes the workbench needs to show the workspace as it now is and update what item is now selected.
Also, the actionbar and the statusbar must be updated based on the new selection.
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 defined how the look like (source & target?) -> e.g. check how JR does it, reuse?
should fire uuid - also ensure consistency
only use id’s?
add new asset
- Which bus should be informed by content changing actions etc...
Moving in Tree (via drag & drop and via actions)
......
Out of scope for this concept
Location encoding
Multi select and execution of action that operate on multiple items