Page tree
Skip to end of metadata
Go to start of metadata

General Issue

When an action is complete, how can it communicate back to the caller in such a way that the caller can take appropriate actions.

Concrete issue that triggered this discussion

Currently in the tree view, when an item is selected, it is also expanded. This is good if for example a property has been added to a contentNdoe. But this is wierd behaviour in all other cases.

In particular, if I move a node with an action, a ContentChangeEvent is fired and the moved item is now expanded. It should not be. Or if i rename a node. Or if I visit a bookmark.
See MGNLUI-2018 - Getting issue details... STATUS  

We need a way to indicate that a node should be expanded in the tree or not, for example when adding a property. Currently it works, but in a generic way (through ContentChangeEvents) and has unwanted side effects, like expanding on programmatic selection.

Options

  1. ContentChangeEvent includes property: isPropertyChange
    1. All of these select methods (WorkbenchPresenter, TreePresenter...) get an extra parameter - isProperty, or isExpandNode?
    2. Or, new "expandNode" methods allow onContentChanged() to explicitly call expandTreeToNode(nodeId, true) in order to expand the target node as well.
      1. or let's call it "ensureVisible" so that it can apply to any content view
    3. DEFAULT OPTION, if we cannot decide on anything better - I plan to go with this solution. CLZ.
  2. An action could fire an additional event: ExpandContentEvent.
    1. A bit weird - because the action does not necessarily know/care that a tree is listening. seems the main difference that listeners need to know about is that it is a property.
      1. PropertyChangeEvent.()?
  3. Pass in the BrowserView or presenter when executing the action
    • same flavor as for MediaEditorAction (passes in MediaEditorView)
    • but AddPropertyAction should not depend on workbench / browser interfaces
      • and WorkbenchAddPropertyAction would be too much overhead
  4. Capability to pass Action Callback object into actionExecutor with onSuccess/onCancel/onError
    1. But who would pass this callback in, in the case of AddPropertyAction?
    2. BrowserPresenter.executeAction()
      1. Problem is that in order to populate callback correctly we would want to do different things for different actions - which we dont want to do in BrowserPresenter.
  5. ActionPresenter /ActionListener concept
    • as being implemented in Direct Asset Upload
    • would not be enough for our use case
      • supposedly the ActionPresenter would be the Actionbar, and it doesn't know about the tree
  6. Chaining of UI actions
    1. we have ConfirmDeleteAction that hands things out to DeleteItemAction
      1. but this is a pain IMO, the fact that an action displays a confirmation should be considered an implementation detail, and not require 2 actions to be configured
    2. Espen has a prototype that he needs to properly chain Workflow's two-step publication
    3. Actions can open dialogs / they should also be able to plug callbacks to proceed or cancel (~ point 4)
      1. this needs one clear approach; neither EditorCallbacks nor sequential pre/postExecute really solve much
      2. such callback should also be able to delegate to another action or command, if really necessary
    4. In a similar fashion, dialog actions should also be responsible for setting save/cancel/additional actions (either in code or config)

Research

What happens when an action fires a ContentChangedEvent on the adminCentral eventBus?

  • BrowserPresenter.onContentChanged()
    • calls getSelectedIds() to get the remembered selected ids.
  • WorkbenchPresenter.select(itemIds)
  • TreePresenter.select(itemIds)
  • TreeViewImpl.select(itemIds)
  • TreeViewImpl.expandTreeToNode(String nodeId)

 

 

  • No labels