ICEfaces
  1. ICEfaces
  2. ICE-5099

compat version of component-showcase MenuBar not always updaing to correct param

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha1
    • Fix Version/s: 2.0-Alpha2, 2.0.0
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      jsf2.0, ICEfaces2.0, compat and comps-compat jars

      Description

      Choose File->Recent->file2->para1 and see para1 as set parameter. If you do the same but choose para3, the parameter is still read as para1. This is consistent whether using FF or Safari

        Issue Links

          Activity

          Judy Guglielmin created issue -
          Judy Guglielmin made changes -
          Field Original Value New Value
          Link This issue depends on ICE-4458 [ ICE-4458 ]
          Judy Guglielmin made changes -
          Salesforce Case []
          Fix Version/s 2.0-Alpha2 [ 10214 ]
          Hide
          Adnan Durrani added a comment -

          I noticed that for some reason the JSF bridge was sending the params that were part of the previous request. So when I tried to debug it, It came across that jsf.js keeps the previous queryString to build the new request in some cases (according to my understanding).

          /**

          • This function does final encoding of parameters, determines the request method
          • (GET or POST) and sends the request using the specified url.
          • @ignore
            */
            req.sendRequest = function() {
            .....
            // Some logic to get the real request URL
            if (req.generateUniqueUrl && req.method == "GET") { req.parameters["AjaxRequestUniqueId"] = new Date().getTime() + "" + req.requestIndex; }

            var content = null; // For POST requests, to hold query string
            for (var i in req.parameters) {
            if (req.parameters.hasOwnProperty)

            Unknown macro: { if (req.queryString.length > 0) { req.queryString += "&"; } req.queryString += encodeURIComponent(i) + "=" + encodeURIComponent(req.parameters[i]); }

            }

          Show
          Adnan Durrani added a comment - I noticed that for some reason the JSF bridge was sending the params that were part of the previous request. So when I tried to debug it, It came across that jsf.js keeps the previous queryString to build the new request in some cases (according to my understanding). /** This function does final encoding of parameters, determines the request method (GET or POST) and sends the request using the specified url. @ignore */ req.sendRequest = function() { ..... // Some logic to get the real request URL if (req.generateUniqueUrl && req.method == "GET") { req.parameters["AjaxRequestUniqueId"] = new Date().getTime() + "" + req.requestIndex; } var content = null; // For POST requests, to hold query string for (var i in req.parameters) { if (req.parameters.hasOwnProperty ) Unknown macro: { if (req.queryString.length > 0) { req.queryString += "&"; } req.queryString += encodeURIComponent(i) + "=" + encodeURIComponent(req.parameters[i]); } }
          Hide
          Adnan Durrani added a comment -

          So once you have clicked a menuItem which has a param defined on it, it becomes part of the queryString, so next time you click a menuItem that doesn't have any param, the jsf bridge takes the previously defined param and add it into the request.

          Maybe its due to the reason that the menuItems are using full submit?

          return iceSubmit(form,this,event);

          Show
          Adnan Durrani added a comment - So once you have clicked a menuItem which has a param defined on it, it becomes part of the queryString, so next time you click a menuItem that doesn't have any param, the jsf bridge takes the previously defined param and add it into the request. Maybe its due to the reason that the menuItems are using full submit? return iceSubmit(form,this,event);
          Hide
          Adnan Durrani added a comment -

          By looking at the generated HTML markup it seems link JSF doing the right thing. As the commandLinkRenderer creates a hidden field for its "params" and also uses a full submit onclick.

          For example:
          If a menuItem is using a param called "myParam", it would generate the following HTML markup.

          <form>
          //menuItem with param
          <a onclick="var form=formOf(this);form['iceform:j_idcl'].value='iceform:menuBar:file:recent:file2:para2:link';
          form['myParam'].value='Para 2';
          return iceSubmit(form,this,event);">

          //menuItem without any param
          <a onclick="var form=formOf(this);form['iceform:j_idcl'].value='iceform:menuBar:edit:copy:link';
          return iceSubmit(form,this,event);

          //generated by commandLinkRenderer for its param
          <input type="hidden" name="myParam" value=""/>
          </form>

          Use case:
          1- Clicked on first menuItem which has a param:

          • myParam hidden field being set to "Para 2"
          • full submit happens
          • bean gets the "Para 2" as "myParam" value.

          2- Clicked on a second menuItem without any param:

          • myParam is still have old value "Para2"
          • full submit happens
          • bean gets still gets "Para 2" as "myParam" value.

          As we can see that myParam value was never cleared, so seems like everything is right. Wondered why "myParam" being cleared in 1.8.2EE.

          Show
          Adnan Durrani added a comment - By looking at the generated HTML markup it seems link JSF doing the right thing. As the commandLinkRenderer creates a hidden field for its "params" and also uses a full submit onclick. For example: If a menuItem is using a param called "myParam", it would generate the following HTML markup. <form> //menuItem with param <a onclick="var form=formOf(this);form ['iceform:j_idcl'] .value='iceform:menuBar: file:recent:file2:para2:link '; form ['myParam'] .value='Para 2'; return iceSubmit(form,this,event);"> //menuItem without any param <a onclick="var form=formOf(this);form ['iceform:j_idcl'] .value='iceform:menuBar:edit:copy:link'; return iceSubmit(form,this,event); //generated by commandLinkRenderer for its param <input type="hidden" name="myParam" value=""/> </form> Use case: 1- Clicked on first menuItem which has a param: myParam hidden field being set to "Para 2" full submit happens bean gets the "Para 2" as "myParam" value. 2- Clicked on a second menuItem without any param: myParam is still have old value "Para2" full submit happens bean gets still gets "Para 2" as "myParam" value. As we can see that myParam value was never cleared, so seems like everything is right. Wondered why "myParam" being cleared in 1.8.2EE.
          Hide
          Adnan Durrani added a comment -

          Comparison between 1.8 and Compat behaviour
          -------------------------------------------------------------------

          1.8


          <a onclick="..form['myParam'].value='Para 2';">

          1. In 1.8 if you click above commandLink, it sets param value and make a full submit. Here is the request header:

          ice.event.captured=iceform:icepnltabset:0:menuBar:view:zoom_out:link
          myParam= Para 2

          We can see myParam was set to Para 2, However firebug shows that myPAram hidden field remains empty in the client side HTML DOM. So when submit happen next time myParam being sent empty(e.g.)

          ice.event.captured=iceform:icepnltabset:txt
          myParam=

          Compat
          ----------
          <a onclick="..form['myParam'].value='Para 2';">

          1. In compat if you click above commandLink, it sets param value and make a full submit. Here is the request header:

          ice.event.captured=iceform:icepnltabset:0:menuBar:view:zoom_out:link
          myParam= Para 2

          We can see myParam was set to Para 2, and firebug shows that myParam hidden field get set with "Para 2". So when submit happen next time myParam being sent with previous value(e.g.)

          ice.event.captured=iceform:icepnltabset:txt
          myParam=Para 2
          Show
          Adnan Durrani added a comment - Comparison between 1.8 and Compat behaviour ------------------------------------------------------------------- 1.8 <a onclick="..form ['myParam'] .value='Para 2';"> 1. In 1.8 if you click above commandLink, it sets param value and make a full submit. Here is the request header: ice.event.captured=iceform:icepnltabset:0:menuBar:view:zoom_out:link myParam= Para 2 We can see myParam was set to Para 2, However firebug shows that myPAram hidden field remains empty in the client side HTML DOM. So when submit happen next time myParam being sent empty(e.g.) ice.event.captured=iceform:icepnltabset:txt myParam= Compat ---------- <a onclick="..form ['myParam'] .value='Para 2';"> 1. In compat if you click above commandLink, it sets param value and make a full submit. Here is the request header: ice.event.captured=iceform:icepnltabset:0:menuBar:view:zoom_out:link myParam= Para 2 We can see myParam was set to Para 2, and firebug shows that myParam hidden field get set with "Para 2". So when submit happen next time myParam being sent with previous value(e.g.) ice.event.captured=iceform:icepnltabset:txt myParam=Para 2
          Adnan Durrani made changes -
          Link This issue depends on ICE-5224 [ ICE-5224 ]
          Adnan Durrani made changes -
          Link This issue depends on ICE-4458 [ ICE-4458 ]
          Adnan Durrani made changes -
          Link This issue blocks ICE-4458 [ ICE-4458 ]
          Hide
          Adnan Durrani added a comment -

          Confirm that ICE-5224 fixes this issue.

          Show
          Adnan Durrani added a comment - Confirm that ICE-5224 fixes this issue.
          Adnan Durrani made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Fix Version/s 2.0.0 [ 10230 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Judy Guglielmin
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: