Context Menu event/config on all Components

[mjack003]

As I develop with the Ext library the "new car" smell is fading and I'm beginning to see some limitations in the project I'm working on. One of these is the lack of widely supported context menus. In this web 2.0 world of webapps, which Ext has so nicely simplified, many will argue but context menus are a must to compete with desktop applications (like in the enterprise app I am currently developing). Yes, the tree panel/grid panel/tab panel partially support context menus as they fire a "contextmenu" event...but it would be nice to see items such as forms/fieldsets etc. support config options for context menus and handle destroying these objects as well when their parent component is destroyed. I'm not aware of any plugins or overrides out there but this should be something natively supported in my opinion.

Am I going off the deepend here? Please post any implementation ideas or links that currently exist for plugins.

I was thinking along the lines of having a "contextMenu" config option for all objects that extend the component class that accepts an array of menu items. This contextMenu would then automatically subscribe to the "contextmenu" (rightclick) of its parent. On destruction of its parent, this menu would also be destroyed. Also, the parent component should have methods for fetching an array of children context menus and manually enabling/disabling/destroying/showing/hiding these items.

Mjack

[Animal]

Sounds a snap to write. Write it and post the code. It might get built in.

[mjack003]

I've built it into my components on a "as needed" basis and am currently researching how to do this on a larger scope as far as extending the component base class. The "new car" smell is fading but I'm still learning how to drive xD I also wanted to get implementation ideas and basic functionality that would be nice to see as far as configuration options on the context menu. Preconditions, custom events, etc.

Mjack

[Animal]

It would just be a config object as passed to the Ext.menu.Menu constructor.



new Ext.Panel({
contextMenu: {
items: [{
text: 'Menu Option 1'
}]
},
...
});


Build the menu in initComponent. In onRender, add a contextmenu listener to the Component's element, to show the Menu.

Add code into the onDestroy method of Component to destroy the Menu, and job's a good 'un.

[mjlecomte]

You might want to piggyback your thoughts on these:

http://extjs.com/forum/showthread.php?p=246051
http://extjs.com/forum/showthread.php?t=52212

[jay@moduscreate.com]

He needs to be a paying support member to post on one of those :(

[mjack003]

@Animal - Working on it now....I really haven't had to extend any of the current Ext classes up until this point. I've been using builder/factory methods so with some trial and error I'm hashing it out.

@MJ - I actually read both those posts while getting ideas and wanted to see how the community felt about context menus in general and to get ideas of others implementations...not to mention I can not post in the feature request forum as jgarcia so kindly pointed out ;) Feel free to link this into that thread to give support of pushing this up the priority list.

Mjack

[mjlecomte]

The second post (feature request/premium) links to the first post which is public forum so you could post there. Nevertheless I'll add a link back here in feature requests, but I'll leave it to you to bump the other...the same guy bumping a thread is not as convincing as others bumping it as well.

Feel free to extend / modify what I was doing in hopes of getting behind at least one extension/terminology though. As you may have noticed the base problem is just having an identifier like "cmenu". I'm using the override to Component that I posted and I'm finding it works quite well for destroying these buggers.

[evant]

The only issue I see is that for certain components you'd expect a context menu to fire in different circumstances.

For example:
Component - On the element
Panel - On the body
Tree - Node context menu
Grid - Row context menu
DataView - Node context menu

Now say I did want a global context menu on my panel (header/footer included), or one on my whole DataView, how would I get this to work?

[mjlecomte]

The only issue I see is that for certain components you'd expect a context menu to fire in different circumstances.

For example:
Component - On the element
Panel - On the body
Tree - Node context menu
Grid - Row context menu
DataView - Node context menu

Now say I did want a global context menu on my panel (header/footer included), or one on my whole DataView, how would I get this to work?

I think I'm underestimating or don't see the problem. All of those inherit from Component. Component will have the abstract method for setting/destroying cmenus. If there's specific needs by the subclass then they override. Component would know about cmenu property though and could destroy the cmenu.

I know that grid is a slightly different animal because it has so many context menu possibilities exposed. But what about "listeners", you define the type you want right? You still on/un them.

If there's specific elements that context menu should be bound to, couldn't one of the arguments for the setter method be an elements/object array?

[mjlecomte]

BTW I'm not saying that my scheme is 100% bullet proof, but it seems for a minor amount of code that some management of these cmenus could be arranged.

[mjack003]

@Evant - Back in the nightmarish days of pre-Ext interface development, I would use the dom level of the 'contextmenu' event as my driver for which context menu to show using event propagation. It was all based on the designers choice of how deeply they wanted to nest these. So if a context menu was configured on a tree panel and another context menu on a node of that tree panel, based on where the user clicks on that tree panel (panel vs node) a different context menu would appear. To answer your question about a context menu on the panel vs the body/header/footer I would say that would be a design choice of where to place that context menu. If the dom heiarchy and event propagation were the driver, you could have all four as long as you had a visible area to designate your panel from its sub components. That's why this is more difficult than simply extending the component class as there are other configuration options to consider and what those would translate to for sub components and parent components. I do however think the component class is the start of moving in the right direction from what I understand of the Ext class model. An abstract level to the nightmare of context menus for all components would be a nice addition for us enterprise application developers.

@MJ - I'll post a link to the public thread.

[evant]

I pretty much agree with your point, that you'd need to provide so many configuration options for different menus in different scenarios, I think it would end up being:

a) Code bloat to handle all the different configurations
b) Confusing

I think you get the most flexibility with the way it is at the moment.

[mjack003]

When I say a "not a simple solution" by no means am I implying code bloat or an unfeasible amount of config options. I think its more rethinking the current implementation of context menus and how they're only configurable from a small subset of Ext visual components. I don't want to sound like I'm complaining, merely getting community feedback on the current implementation and if there's even a need for wider support of context menus...hence the poll. I know in large applications context menus are a neccessary evil so I'll do more reading and post back what I implement in my project.

[evant]

Absolutely, I'm just giving my first thoughts on the subject. We'll get some feedback and we'll see what everyone else thinks.

[mjlecomte]

I don't want to sidetrack this thread, but missing notifications on this thread finally motivated me to post something:
http://extjs.com/forum/showthread.php?t=55668