Details
-
Type: New Feature
-
Status: Closed
-
Priority: Critical
-
Resolution: Fixed
-
Affects Version/s: 1.5
-
Component/s: ICE-Components
-
Labels:None
-
Environment:Operating System: All
Platform: All
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial
Description
This component would implement a menuPopup (context menu) component.
When the user clicked the context-menu mouse button on their browser/platform, the menuPopup component would display at the mouse coordinates. Users could then use the mouse to navigate through the menus and select a menu item. Pressing ESC or click off the menu, or the menu losing focus should close the menu.
Additional reqs.:
- menu must position based on the mouse coord. where the button was pressed.
- menu could move its position and even the direction that sub-menus open
depending on proximity to top/bottom/left/right edges of the window (nice-to-have).
- Originally we thought that the menuPopup should support an event that fires when it is about to be displayed, which would allow the application to dynamically alter the state/contents of the menuPoup immediately prior to it's display, if desired. But, since the existing menuBar does not do a server round-trip to show its sub-level menuitems, we're not going to make menuPopup do that either.
- The clientId of the component that triggered the menuPoup should be included in the event parameters, so that when the menuitem is selected and a form submission occurs, the menuPopup's decode could know that clientId, possibly to include in an event.
- For a component to be able to have a menuPopup, that component's rendered html would need to include certain attributes that call Javascript functions. That means that menuPopup support has to be added on a component by component basis. Each supporting component would have an attribute like >> menuPopup="menuPopupComponentId" <<. So, there's no need to place a menuPopup component in any special place in the component hierarchy (except in a FORM, like a regular menuBar requires), since the menuPopup doesn't dictate the relationship, but rather each component with a menuPopup attribute does.
A recommended approach to implementing this feature is to create a new ice:menuPopup component that either extends or uses an ice:menuBar. This component would support the exact same menu sub-components used by the ice:menuBar component (ice:menuItem and ice:menuSeparator, etc.) to define a context menu. The differences between the popupMenu and the menuBar are that the popupMenu would support:
- Only a vertical orientation, that is, the top-level menuItems and menuSeparators would appear vertically stacked.
- We were think about constricting the styling so that top-level menuitems and sub-level menuitems would use the same style classes, but decided to just leave in the existing rendering behaviours, and just make the two CSS classes have the same content.
When the user clicked the context-menu mouse button on their browser/platform, the menuPopup component would display at the mouse coordinates. Users could then use the mouse to navigate through the menus and select a menu item. Pressing ESC or click off the menu, or the menu losing focus should close the menu.
Additional reqs.:
- menu must position based on the mouse coord. where the button was pressed.
- menu could move its position and even the direction that sub-menus open
depending on proximity to top/bottom/left/right edges of the window (nice-to-have).
- Originally we thought that the menuPopup should support an event that fires when it is about to be displayed, which would allow the application to dynamically alter the state/contents of the menuPoup immediately prior to it's display, if desired. But, since the existing menuBar does not do a server round-trip to show its sub-level menuitems, we're not going to make menuPopup do that either.
- The clientId of the component that triggered the menuPoup should be included in the event parameters, so that when the menuitem is selected and a form submission occurs, the menuPopup's decode could know that clientId, possibly to include in an event.
- For a component to be able to have a menuPopup, that component's rendered html would need to include certain attributes that call Javascript functions. That means that menuPopup support has to be added on a component by component basis. Each supporting component would have an attribute like >> menuPopup="menuPopupComponentId" <<. So, there's no need to place a menuPopup component in any special place in the component hierarchy (except in a FORM, like a regular menuBar requires), since the menuPopup doesn't dictate the relationship, but rather each component with a menuPopup attribute does.
A recommended approach to implementing this feature is to create a new ice:menuPopup component that either extends or uses an ice:menuBar. This component would support the exact same menu sub-components used by the ice:menuBar component (ice:menuItem and ice:menuSeparator, etc.) to define a context menu. The differences between the popupMenu and the menuBar are that the popupMenu would support:
- Only a vertical orientation, that is, the top-level menuItems and menuSeparators would appear vertically stacked.
- We were think about constricting the styling so that top-level menuitems and sub-level menuitems would use the same style classes, but decided to just leave in the existing rendering behaviours, and just make the two CSS classes have the same content.
Issue Links
- is duplicated by
-
ICE-1778 ContextMenu for ICEfaces components
- Closed
Lower priority, out of scope for v1.1. release.