ICEfaces
  1. ICEfaces
  2. ICE-9771

menuItem actionListener not firing consistently when using menuModel attribute

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Won't Fix
          • Affects Version/s: EE-3.3.0.GA_P01
          • Fix Version/s: 4.0.BETA, EE-3.3.0.GA_P02, 4.0
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            jsf 2 ace
          • Assignee Priority:
            P1

            Description

            when creating a menu dynamically, the actionListener is not always firing. For example, see the xhtml and attached bean.
            There are 6 menu items,
            item 1-1
            item 1-2

            item 2-1
            item 2-2

            item 3-1
            item 3-2

            when the app is deployed, you can fire the first 4 items starting at top and see on server log that the actionListener has been fired.
            click on 3-1 and no actionListener is fired.
            refresh the page and 3-1 and 3-2 can get fired but then other's don't get fired.

            No decodes on this component, so hard to track. Note that without ace:ajax, ice.s is being used (like submitting an entire form of commandButton or pushButtons).

            here is the console for 2 successful and 1 unsuccessful submits:-
            The successful submit appears like this (here are two):-
            [window] full submit to http://localhost:8080/menusc/12500TheirsNoIds.jsf javax.faces.execute: @all javax.faces.render: @all javax.faces.source: menuForm:menuTable:2:Item_2 view ID: v7xcbxz8 event type: click bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] applied updates >> update["javax.faces.ViewState"]: -739589806292141809:8385346342820842498.... eval: var iceFormIdList=['menuForm', 'v7xcbxz8.... extension bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] persisted focus for element "" bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] persisted focus for element "" bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] full submit to http://localhost:8080/menusc/12500TheirsNoIds.jsf javax.faces.execute: @all javax.faces.render: @all javax.faces.source: menuForm:menuTable:0:Item_2 view ID: v7xcbxz8 event type: click bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] applied updates >> update["javax.faces.ViewState"]: -739589806292141809:8385346342820842498.... eval: var iceFormIdList=['menuForm', 'v7xcbxz8.... extension bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] persisted focus for element "" bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] persisted focus for element "" bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>

            If you continue to click on the items, then you start to get console like this and the actionListener does not get fired:-

            [window] full submit to http://localhost:8080/menusc/12500TheirsNoIds.jsf javax.faces.execute: @all javax.faces.render: @all javax.faces.source: menuForm:menuTable:2:Item_1 view ID: v7xcbxz8 event type: click bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] applied updates >> update["javax.faces.ViewState"]: -739589806292141809:8385346342820842498.... eval: var iceFormIdList=['menuForm', 'v7xcbxz8.... extension bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>
            [window] persisted focus for element "" bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106:1291 <http://localhost:8080/menusc/javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_3_0_140106>

              Issue Links

              depends on

              Bug - A problem which impairs or prevents the functions of the product. ICE-7285 ace:menubar - MenuModel does not get reevaluated when re-initializing the model

              • Major - Major loss of function.
              • Closed

              Improvement - An improvement or enhancement to an existing feature or task. ICE-7347 Create model objects for ace:submenu, ace:menuItem, ace:multiColumnSubmenu, ace:menuColumn, and ace:menuSeparator

              • Major - Major loss of function.
              • Open

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Judy Guglielmin added a comment - - edited

                contain 12500.xhtml is the correct page to look at the final item in the data table as it does not fire the actionListeners.

                Show
                Judy Guglielmin added a comment - - edited contain 12500.xhtml is the correct page to look at the final item in the data table as it does not fire the actionListeners.
                Hide
                Permalink
                Judy Guglielmin added a comment -

                as you requested. I did not put the info on the params being empty when using ace:ajax. We should probably have a test case for that first.

                Show
                Judy Guglielmin added a comment - as you requested. I did not put the info on the params being empty when using ace:ajax. We should probably have a test case for that first.
                Hide
                Permalink
                Arturo Zambrano added a comment - - edited

                After doing some research, I remembered that about two years ago there were some other issues with menus built from a model, and the solution was to recreate the model at every request. I tried that in this test case, and all the action listeners were now fired successfully.

                In ListMenuBean.java, you just add initMenu() to getMenuModel as follows:

                public MenuModel getMenuModel()
{
	initMenu();
	return menuModel;
}

                In ListMenuModelBean.java, you just modify getListMenuModelNoId() as follows:

                    public List<MenuModel> getListMenuModelNoId(){
        listMenuModelNoId = new ArrayList<MenuModel>();
        listMenuModelNoId.add(buildMenuModelNoId("1"));
        listMenuModelNoId.add(buildMenuModelNoId("2")); 
        listMenuModelNoId.add(buildMenuModelNoId("3"));
    	return this.listMenuModelNoId;
    }

                I'll look for more information about those older issues and try to come up to a conclusion regarding these problems with menu models.

                Show
                Arturo Zambrano added a comment - - edited After doing some research, I remembered that about two years ago there were some other issues with menus built from a model, and the solution was to recreate the model at every request. I tried that in this test case, and all the action listeners were now fired successfully. In ListMenuBean.java, you just add initMenu() to getMenuModel as follows: public MenuModel getMenuModel() { initMenu(); return menuModel; } In ListMenuModelBean.java, you just modify getListMenuModelNoId() as follows: public List<MenuModel> getListMenuModelNoId(){ listMenuModelNoId = new ArrayList<MenuModel>(); listMenuModelNoId.add(buildMenuModelNoId( "1" )); listMenuModelNoId.add(buildMenuModelNoId( "2" )); listMenuModelNoId.add(buildMenuModelNoId( "3" )); return this .listMenuModelNoId; } I'll look for more information about those older issues and try to come up to a conclusion regarding these problems with menu models.
                Hide
                Permalink
                Arturo Zambrano added a comment -

                Closing issue as Won't Fix. The solution consists in recreating the menu model at every request, as illustrated above.

                In AbstractMenuModel, all menu child components are set to transient, and the list of children of the root menu component is always cleared before building the menu from a model. This operation is done at every lifecycle. AbstractMenuModel was geared to support dynamically changing menu models rather than unchanging menu models, after some requests from a customer a couple of years ago. ICE-7285 contains a summary of some of the changes.

                So, it is recommended to always supply a new menu model, with new objects, since certain object references could be lost after rebuilding the menu from a model. This recommendation will be added to the wiki.

                Show
                Arturo Zambrano added a comment - Closing issue as Won't Fix. The solution consists in recreating the menu model at every request, as illustrated above. In AbstractMenuModel, all menu child components are set to transient, and the list of children of the root menu component is always cleared before building the menu from a model. This operation is done at every lifecycle. AbstractMenuModel was geared to support dynamically changing menu models rather than unchanging menu models, after some requests from a customer a couple of years ago. ICE-7285 contains a summary of some of the changes. So, it is recommended to always supply a new menu model, with new objects, since certain object references could be lost after rebuilding the menu from a model. This recommendation will be added to the wiki.
                Hide
                Permalink
                Ken Fyten added a comment -

                The ultimate solution for this issue that would remove the currently necessary workaround of building the model in the gettor is described in ICE-7347.

                Show
                Ken Fyten added a comment - The ultimate solution for this issue that would remove the currently necessary workaround of building the model in the gettor is described in ICE-7347 .

                  People

                  • Assignee:
                    Arturo Zambrano
                    Reporter:
                    Judy Guglielmin
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    3 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: