ContextMenu and macrosubstituion

[bleathem]

Hello all,

We have an initial implementation of the rich:contextMenu -- RF-10197, currently in the feature/contextMenu branch on github.  However it does not currently have the "macrosubstitution" support that the RichFaces 3 contextMenu had.  I'm tracking this feature in the following jira issue: RF-11842.

How useful would the community find the contextMenu to be without the macrosubstitution feature?  Should we be pushing to get this supported with the initial offering of the contextMenu?

Brian

[lfryc]

Just note it would be handy use same principle for all popup components as we should push unified approach:

• contextMenu, popupPanel, tooltip, dropDownMenu, calendar?

Component could be handled by JavaScript API only and actual content could be provided using f:param / a4j:hashParam.

[blabno]

macrosubstitution look very cool, but i've never used it and think we could live without it.

[pjotrovsky]

Hi,

I find it useful for handling of menuItems dependent on user permissions on, for instance, the selected dataTable row without need to make a server round-trip,

i.e. something like this:

<rich:dataTable>

.....

<rich:componentControl event="rowselect" target="contextMenu" operation="show">

     <f:param name="header" value="#{currentRowObject.description}">

     <f:param name="displayItem" value="#{currentRowObject.somethingAllowed}">

...........

<rich:contextMenu id="contextMenu">

     <rich:menuItem id="contextMenuHeader" enabled="false">{description}</richMenuItem>

     <rich:menuItem style="display: {displayItem}">

[pjotrovsky]

Hi there,

i`m testing the contextMenu in 4.2.0-SNAPSHOT from Github.

Env: JDK 1.6_30,  GF 3.1.1, Mojarra 2.1.6 (SNAPSHOT 20111206)

I figured out, how to get parameters into the contextMenu(Table ContextMenu sample) without macro-substitutions, see attachment (looks funny, but it works):

-in the  "selectionchange" ajax request re-render only the second menuItem,

-the first menuItem must be there not re-rendered, since if one re-renders the whole contextMenu or all menuItems - it/they become kind of detached from DOM!

(in the menu-base.js two methods fail and don`t return any "parentMenu" - they can not find any "div" parents of contextMenu/menuItem with specified "-ctx-" CSS-classes:

__getParentMenuFromItem

menu = item.parents('div.' + this.options.cssClasses.itemCss).has('div.' + this.options.cssClasses.listContainerCss).eq(1);  --> returns [] after re-render

__getParentMenu

var menu = $(this.element).parents('div.' + this.options.cssClasses.itemCss).has('div.' + this.options.cssClasses.listContainerCss).eq(0); ->returns [] after re-render

)

Another problem is in the contextmenu.js itself, method

show : function(e) - there is no check if the attached/target is defined  while calling the parent element`s parent.selectionClickListener(e) -

the search with rf.$(this.target) fails before the parent is checkec for "undefined".

By the way, i created the showcase profile for Glassfish 3.1, called gf3/Eclipse Livelink (goes to showcase-root), but it`s hard to get the push working, since the JMS Connection Factory retrieval is hardcoded in the org.richfaces.demo.push.JMSInitializer.

[pjotrovsky]

Couldn`t attach source, so here You can see what i mean:

[ruser]

We use macrosubstituions heavily in all table context menus.

Absense of this feature prevents RF 3-4 migration.

Any update when this feature will be implemented?

[true_mykola]

May be this workaround (proposed by Pjotr) works for static menu but it definitely doesn't for dynamic menu which items are rendered using some collection. Like this, for example:

<rich:contextMenu id="myCtxMenu" attached="false" submitMode="ajax">
    <c:forEach items="#{MbContextMenu.currentMenuItems}" var="ctxItem">
        <rich:menuItem value="#{ctxItem.label}" action="#{MyBean.goThere}" rendered="#{ctxItem.actionItem}">
            <f:setPropertyActionListener value="#{ctxItem}" target="#{MbContextMenu.selectedCtxItem}"/>
        </rich:menuItem>
        <rich:menuItem value="#{ctxItem.label}" onclick="openModal(#{ctxItem.id}, #{MbContextMenu.actionParams[ctxItem.action]['panelName']})"
                        rendered="#{ctxItem.modalItem}"
                        >
        </rich:menuItem>
        <rich:menuItem value="#{ctxItem.label}" rendered="#{ctxItem.runnableItem}"
            onclick="runImmed(#{ctxItem.id})">
        </rich:menuItem>
    </c:forEach>
</rich:contextMenu>

Here, #{MbContextMenu.currentMenuItems} depends on selected entry in rich:extendedDataTable. And it's impossible to add either h:panelGroup or a4j:outputPanel to wrap c:forEach inside rich:contextMenu to refresh it instead of whole menu because in this case context menu just ignores this block and everything inside it, i.e. empty context menu is rendered. Is there any other way to workaround described problem (that menu doesn't appear after rerendering) or i have to wait for future RF versions? Now i'm using RF 4.2.2 Final.

[robert.raksi]

Thanks Andreev for the solution, you saved my life

[pjotrovsky]

I opened an issue: [RF-14023] rich:contextMenu - on ajax re-render the destroy function doesn`t clean up properly - JBoss Issue Tracker.

I`m currently testing the integration path of 4.5.5-SNAPSHOT, had hard times to get ITs working because of failing Warp observers, but smoke tests are done.

Does anyone have an idea, where the original client event can be stored (or retrieved after) just before ajax submit request (it worked in RF 3.3)?

I`m using a kind of hack like:

<a4j:ajax execute="@form" event="selectionchange" listener="#{extTableSelectionBean.selectionListener}" render="contextMenu"

                          onbeforesubmit="if(event.type==#{rich:component('contextMenu')}.options.showEvent){RichFaces.ui.originalEvent=event}"

                          oncomplete="if(RichFaces.ui.originalEvent){#{rich:component('contextMenu')}.show(RichFaces.ui.originalEvent);RichFaces.ui.originalEvent=null}"/>

in order to show the contextMenu popup at the proper position.