ContextMenu Extender, anyone?

  • Article

The Ajax Control Toolkit has a bunch of controls wish-listed and we would like to deliver as many as possible to our customers. One of our new contributors, Ziemowit Skowronski, has volunteered to author a new control which will behave like a context menu. It will prevent the default browser menu from showing up when you right click and show you a custom menu and provide you with richer, more relevant functionality. We would have to essentially override the contextmenu event and show a popup. The new context menu could easily use the existing FloatingBehavior support in the Toolkit to show a custom menu control.

 

Name of the control: ContextMenuExtender

TargetControl: Control

Properties: I am almost stealing this from the HoverMenu control in the Toolkit. The ContextMenu is the HoverMenu handling the contextmenu event instead of the mouseover/mouseout events. We could reuse most of the functionality in that control.

 

· TargetControlID: ID of the element, right clicking on which will cause the context menu to show

· PopupControlID: ID of the menu popup that will serve as the context menu

· Position: Position of the menu popup with respect to the target control. Any position supported by PopupBehavior?

· ContextMenuCssClass: Name of the css class that will be applied to the menu popup element.

 

Accessibility: When the target control is focusable the ContextMenu should be able to be activated using the keyboard alone so the extender needs to support keyboard events on the target control as well. The popup panel should have the features expected of an accessible control like semantic html, alternate text, high contrast support, keyboard support and more. This would be a to-do for the website developer though and not the control author since the Extender consumes whatever Menu Control is passed to it.

 

International: Would there be any left-to-right/right-to-left concerns we should have if we are exposing the Position property? Users can make their page globally aware using that, correct?

 

Usability: This is something that end users who deploy this control should take into consideration. Right-clicking in a browser to expose non-browser menus is not something that users will discover intuitively. It should be considered that the control needs to communicate in some way that it has a contextmenu that is not the default browser one. It needs to be somehow advertised that there is more possible with the target control beyond just clicking and/or hovering over it. Talking about usability, what would be the Safari story? Would any Macintosh users like to chime in?

 

Any more feature requests, ideas?

------------

*update*

 

Some more new ideas...

 

Chad Smith, a Toolkit enthusiast is working with Ziemowit on the ContextMenu. He suggested the idea of sharing code among PopupControl and ContextMenu since PopupControl is fired by a left mouse button click and ContextMenu will be fired by a right mouse button click. So the only distinction between the two being the value of the property "InvokedBy"

 

I really liked that idea. Taking it a step further what if we could observe more code sharing?

 

  • Instead of restricting it to right-button and left-button clicks we could set it to be the event that fires “show” on the popup and make it more generic. We could then add the “MouseHover” event to that set and take care of HoverMenu support as well.
  • If we could have a similar “DismissedBy” property which would be set to “MouseUnHover” in case of the HoverMenu, “BodyClick” for the PopupControl and the ContextMenu that would make the model more consistent.
  • All the core functionality could be moved into a “Menu” class and the classifications on how the menu gets shown would be the three child classes with relevant values for InvokedBy and DismissedBy (those would need the element whose event needs to be fired as well, to create the handlers; for example in case of body click). These properties do not need to be publicly exposed but will remain the distinguishing features and could stay protected.

Sounds more object oriented?