Navigation in Magnolia 5.0 is the application entry point situated on the left-side and it is made up of several UI components. These are basically representing working areas (e.g. personal, content, global settings) where each working area is made up by one or more accordion-like menus (navigation groups). The number and type of working areas and menus displayed to a user will depend on his or her privileges/role. See also Andreas' mockups concerning the main menu.

Navigation should not only trigger an app status change, but also correctly reflect the current app status (basically, the current Place displayed). Whilst Vaadin's Accordion component serves well the basic purpose of selecting an action to be performed (e.g. show me the website tree), it has serious shortcomings when it comes to the following three use cases:

  1. Navigating away from a place may require confirmation from user. In this case, no matter what the user decides, the accordion is immediately repainted opened at the item the user clicked on, whereas it should wait for the user's answer and react accordingly. As it is now, it is very easy to end up in an inconsistent situation where the menu no longer represents the app current status.
  2. Navigating with browser's buttons does not update the navigation status
  3. Entering the app via bookmark should not only select the correct place (as it actually does) but also correctly update the navigation status.

The approach followed by patching Vaadin's accordion and let it react to info.magnolia.ui.framework.place.PlaceChangeEvent has not worked out. What I tried to do was overriding com.vaadin.ui.TabSheet.changeVariables(Object, Map<String, Object>) on the server-side. That method is called immediately after an onClick event on a menu item on the client-side and basically, after updating the menu status on the server, asks the client code to repaint the menu (e.g. open the selected tab, close the others). In order to solve the use case #1 mentioned above, the request for repainting was not performed immediately rather in info.magnolia.ui.framework.place.PlaceChangeEvent.Handler.onPlaceChange(PlaceChangeEvent). While it worked for that use case, this solution prevented the menu from being updated in case of clicks which do not trigger a PlaceChangeEvent. The problem is aggravated by the fact that also clicking on work area choice buttons should react on PCE (the correct workarea should show up). Moreover, this solution does not work for cases 2 and 3.

We need some generic mechanism to keep place change events and navigation in synch. Most likely, information about the selected workarea/navigation group/menu item item should be kept in the URI and extracted much like we do with Place tokens to recreate the correct Place. So far navigation has been kept somehow separated from the rest of the UI architecture but we have to find a way to integrate it. Should possibly info.magnolia.ui.framework.activity.ActivityManager be aware of navigation and responsible for updating it?