You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Story

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

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.

When the workbench receives a ContentChangedEvent it must not change selection to the changed node/property because this event is meant to make the workbench stay in sync when the workspace changes. It can come from anywhere, another app and possibly even another user.

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


  • No labels