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


In Pulse we need to provide a message detail view displaying the entire message text and, in some cases such as a workflow item message, also allow for performing actions on it. This concept is mainly about the workflow use case but it could apply to any apps wishing to allow action execution on a message they send to Pulse. See also the story we intend to implement 

UX design and screens

Workflow requirements

In 5.0 workflow is an EE feature only, therefore the

  • Workflow items tab should display only if the workflow module is present. (A workflow item is basically a workflow process waiting for an approval or revision, such an page publication after some editing. See also Concept - Review Process (Workflow))
  • The workflow item detail view
    • is configurable
      • can re-use existing dialog configurations
      • can get the dialog to use if specified in the work item message itself
      • fallbacks to a default view in case no specific view is found
    • can display an action bar where available actions are configured based on roles, groups or other criteria.
    • should allow the reviewer to comment on it and give reasons for i.e. rejection.
    • should allow the reviewer to look at and restore previous versions of the item being submitted (will open the workflow app for this)
    • should allow the reviewer to visually compare the item being submitted with any of its previous versions (see MGNLDIFF)  (will open the workflow app for this)
    • should allow the reviewer to have a quick overview of the dependencies the item being submitted has on other items, i.e. pages, media assets, etc. (see MGNLCDEP



  • registers a onDoubleClickItem listener on the messages list

onDoubleClickItem event

  • PulseMessagePresenter
  • retrieves Message from message id passed by the event
  • calls Message.getDialogName()
    • if dialogName is blank use the default one.
  • calls DialogDefinition.getFormDefinition()
  • gets further fields to be rendered which may be in the work item Message
  • gets an optional configured ActionbarDefinition, i.e. via DialogDefinition.getActionbarDefinition() (we probably need to subclass DialogDef and not add ActiobarDefinition to it)
  • combines FormDefinition and additional work item fields as a plain Vaadin BeanItem (i.e. there's no JCR item involved here) and passes them to a buildFactory
  • buildFactory returns a FormView
  • builds the optional actionbar 
  • combines FormView and ActionBar in a MessageDetailView (see if it's possible to reuse DialogWithActionbar being implemented for Concept - Image Editor)
  • sets the MessageDetailView in PulseMessagesView
  • hides the messages list view and displays MessageDetailView


  • knows how to go back to the list of messages

Default MessageDetail dialog configuration example

Exploratory implementation

This concept is actually the result of some preliminary exploratory implementation to see if what I had in mind was actually doable. The code is in Git under magnolia_ui project, branch workflow-message-detail

Notes - Ideas 


  • MessageType enum
    • new type WORKITEM has been added;
  • Message class
    • add dialogName property (String)
      • name of the dialog to display the message details
      • if empty, use default
      • if not existing, use default, but send an error message to the superuser / display a notice, that the proper dialog couldn't be displayed?
    • add data property (String) 
      • serialised data (JSON?)
    • add dataClass property (String)
      • name of the class that handles the data property - used by the dialog defined above;
      • if missing/empty, use Map<String,String>
      • if the class does not exist, send an error message to the superuser
    • Message now implements Map<String,Object>, so no need to add extra property (getters/setters for the basic properties like id, subject, message, ... have been preserved)
  • MessageStore class
    • marshallMessage / unmarshallMessage methods have been updated to handle the Map nature of the Message
  • Other:
    • we should demo the use of new properties in the workflow module