Dynamic Menus

The Perspective Subsystem reclassifies the Core UI into a number Extension Points where Perspective Developers can provide new or alternate menu details dynamically that contribute to a different Perspective for the logged in user. This means changing the current menuing system to be defined (more) programmatically than the rhq/common/menu/menu.xhtml delivered with Jon 2.3.

The approach

Modify the exiting menu.xhtml to use JSF value binding to retrieve live-bean menu content where ever possible.
Before

    <h:outputLink value="/">
        <h:graphicImage value="/images/JBossLogo_small.png"/>
    </h:outputLink>

After

   <h:outputLink value="/">
	<h:graphicImage value="#{PerspectivesMenuUIBean.logo.iconUrl}"
	    width="#{PerspectivesMenuUIBean.logo.iconWidth}"
	    height="#{PerspectivesMenuUIBean.logo.iconHeight}"
	rendered="#{PerspectivesMenuUIBean.logo.rendered}" />
  </h:outputLink>

What it looks like

Before

After applied Perspective changes
Programmatically added new menu item(w icons) to menu.overview_Before extension point
Programmatically changed logo image and removed previous Clouds menu items

Programmatic changes:

Unresolved tasks

At this time the goal of this analysis was to determine the cleanest approach, eliminate incorrect approaches and finally show that the approach will enable perspective goals.

Lots of small conversions need to occur

Defining objects to record all the dynamic menu item information will take a few more hours. There are many options and configurations used in menu.xhtml.

Numerous jsf tag attributes need to be added to Menu* beans.

I'm not sure how much we want perspective developers to be able to change(Ex. width, length,etc). My guess is everything that is currently configurable or used by JSF menu items should be get/set attributes.

Menu Extension Points need to be exhaustively enumerated

By redefining the existing menu items programmatically, modification of existing Core UI can be achieved if we store and uniformly address all the MenuItem definitions. This dovetails with need to iterate all possible extension points.

• menu.logo
• menu.overview
• menu.overview_BEFORE
  • menu.overview.dashboard
• etc.

Other approaches excluded

Before going down the path of redefining the menu programmatically, I investigated alternative approaches to dynamically modifying the menu.

Dynamically reuse existing JSF AjaxViewRoot

A few attempts were made to dynamically modify and programmatically capture the rendered JSF component tree using a PhaseListener. The approach being that core menu is already being generated correctly and some perspective changes are only shortlived changes tailored for a specific user. To summarize, the JSF lifecycle does not easily allow persistence of programmatic changes.