The rich:dropDown menu is designed keeping in mind that it should not be used for contextMenu purpose. We have a rich:contextMenu component in the TODO list. However, it will not scheduled for the nearest versions.
rich:dropDown menu creates own hierarchy in the browser DOM (and in the component tree on the server side as well) each time it is declared. This is overhead in case of using inside the iteration context such as table or tree. The context menu should be shared and parametrized to be optimized well. That was the reason we separate those two kind of menus
Sergey, is it only a matter of performance ? I mean I have typical trees with two kind of nodes: folder and documents. So I need just two beans and two menu prototypes, but of course I need to place a menu on each node.
While in this way beans are shared among nodes of the same types, I miss how I could share elements on the component tree to optimize further.
Any hint ?