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
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Ken Fyten
created issue -
Icefaces Administrator
made changes -
Field | Original Value | New Value |
---|---|---|
issue.field.bugzillaimportkey | 744 | 12000 |
Ken Fyten
made changes -
Affects Version/s | 1.5 [ 10027 ] | |
Affects Version/s | 1.0.1 [ 10025 ] |
Ken Fyten
made changes -
Priority | Minor [ 4 ] | Major [ 3 ] |
Ken Fyten
made changes -
Fix Version/s | 1.6 [ 10031 ] |
Ken Fyten
made changes -
Assignee | Rob Mayhew [ rob.mayhew ] |
Michael Thiem
made changes -
Michael Thiem
made changes -
Priority | Major [ 3 ] | Critical [ 2 ] |
Ken Fyten
made changes -
Assignee | Mark Collette [ mark.collette ] |
Ken Fyten
made changes -
Issue Type | Improvement [ 4 ] | New Feature [ 2 ] |
Assignee Priority | P3 |
Ken Fyten
made changes -
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, or press-ESC or click off the menu to close the menu. We should be able to leverage or perhaps even just extend the existing menuBar and/or menuItem components for this. Specific complicating factors are: - menu must position based on the mouse coord. when the button was pressed. - menu must 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). - menu must close if focus leaves the menu, or ESC pressed. Rob, please perform an initial analysis of the effort/impacts associated with this new component. |
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, or press-ESC or click off the menu to close the menu. We should be able to leverage or perhaps even just extend the existing menuBar and/or menuItem components for this. Additional reqs.: - menu must position based on the mouse coord. when the button was pressed. - menu must 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). - menu must close if focus leaves the menu, or ESC pressed. - The contextMenu should support an event that fires when it is about to be displayed, this will allow the application to dynamically alter the state/contents of the contextMenu immediately prior to it's display, if desired. Of course, the ID of the component that is the target for the contextMenu should be included in the event parameters. A recommended approach to implementing this feature is to create a new ice:contextMenu component. 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 contextMenu. The differences between the contextMenu and the menuBar are that the contextMenu would support: - Only a vertical orientation, that is, the top-level menuItems and menuSeparators would appear vertically stacked. However, the styling for the top-level menu items should be identical to any child submenus, unlike the menuBar root level menuitems which have distinct styling from the submenus. - The ability to specify a "for" attribute that can be used to indicate which other components this contextMenu is associated with. Right-clicking (or clicking the defined "context-menu" mouse button) on one of the components in the "for" attribute would result in the contextMenu appearing at the mouse-location. |
Ken Fyten
made changes -
Assignee Priority | P3 | P1 |
Mark Collette
made changes -
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, or press-ESC or click off the menu to close the menu. We should be able to leverage or perhaps even just extend the existing menuBar and/or menuItem components for this. Additional reqs.: - menu must position based on the mouse coord. when the button was pressed. - menu must 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). - menu must close if focus leaves the menu, or ESC pressed. - The contextMenu should support an event that fires when it is about to be displayed, this will allow the application to dynamically alter the state/contents of the contextMenu immediately prior to it's display, if desired. Of course, the ID of the component that is the target for the contextMenu should be included in the event parameters. A recommended approach to implementing this feature is to create a new ice:contextMenu component. 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 contextMenu. The differences between the contextMenu and the menuBar are that the contextMenu would support: - Only a vertical orientation, that is, the top-level menuItems and menuSeparators would appear vertically stacked. However, the styling for the top-level menu items should be identical to any child submenus, unlike the menuBar root level menuitems which have distinct styling from the submenus. - The ability to specify a "for" attribute that can be used to indicate which other components this contextMenu is associated with. Right-clicking (or clicking the defined "context-menu" mouse button) on one of the components in the "for" attribute would result in the contextMenu appearing at the mouse-location. |
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. |
Ken Fyten
made changes -
Fix Version/s | 1.7DR#2 [ 10110 ] | |
Affects | [Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial] |
Ken Fyten
made changes -
Summary | Create new menuPopup component. | Create new menuPopup component |
Ken Fyten
made changes -
Assignee | Mark Collette [ mark.collette ] | Yip Ng [ yip.ng ] |
yip.ng
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Fix Version/s | 1.7 [ 10080 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Assignee Priority | P1 | |
Assignee | Yip Ng [ yip.ng ] |