Menu and Menubar

Menus and menu items (except for sliding menus) now take as much width as they need, instead of having a fixed width. If a fixed width is desired, it can be set by specifying a width in a CSS rule for the .wijmo-wijmenu class and also a rule for the following selector: .wijmo-wijmenu .wijmo-wijmenu-parent .wijmo-wijmenu-child. To change the width for sliding menus, the selector is .ice-ace-menu-sliding .wijmo-wijmenu-container.

Building menus from a model can create multiple different issues on the server side. To avoid these issues it is advised to always generate a new model object whenever the accessor method (e.g. getModel()) in the bean is invoked. So, instead of creating a single model object in the bean constructor, create a separate method that will build and return a new model object. This way, if multiple menu instances use the same model on a page or if the page has complex rendering/loading mechanisms that could keep a menu in the view while reloading it, then there won't be server-side errors related to having the same components in the view already, since when building a model one has to create the actual component instances.

There's a known issue when using MyFaces and building menus from a model. If the bean where the model is created is using a scope different than @SessionScope and the menu is not recreated at every request (e.g. only created in the constructor), then MyFaces will hand in a corrupt model object with loss of information to the component code. Visually, this looks like the menu disappears at the first dynamic update. The problem is related to serialization in MyFaces.
This situation can be fixed by adding the following markup in the deployment descriptor:

<context-param>
 <param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
 <param-value>false</param-value>
 </context-param>

Alternatively, if adding the above parameter is not possible. This problem can be avoided by simply using @SessionScope in the bean that creates the model object. If this is not possible either, another solution is to simply generate the model at every request (e.g. in the getter method for the model).

There seems to be an issue when using a custom style class, not overriding certain styles defined by the current theme, even though the custom style class is added correctly at the end of the 'class' attribute of the root container. The way to fix this is by either forcing rule precedence by adding the '!important' keyword at the end of each rule in the custom class or by simply making the custom class more specific, in order to make it have more precedence. For example, instead of '.myClass', define the custom class as 'div.myClass'.

Whenever a menu item is dynamically changed, without updating the entire menu in which it is, it may appear to lose some styling and behaviour. This is so, because the nodes corresponding to the menu item were replaced without re-initializing the whole menu on the client, which applies additional styling and behaviour. For these cases, simply set the forceMenuUpdate attribute to true in an event listener when the change in the menu item occurs, and the whole menu will be updated to keep all the necessary styling and bahaviour for the menu to work properly. This attribute will be automatically set back to false by the component after being consumed.